Best practices voor implementatie en clusterbetrouwbaarheid voor Azure Kubernetes Service (AKS)
Dit artikel bevat aanbevolen procedures voor clusterbetrouwbaarheid die zijn geïmplementeerd op implementatie- en clusterniveau voor uw AKS-workloads (Azure Kubernetes Service). Het artikel is bedoeld voor clusteroperators en ontwikkelaars die verantwoordelijk zijn voor het implementeren en beheren van toepassingen in AKS.
De aanbevolen procedures in dit artikel zijn ingedeeld in de volgende categorieën:
Best practices op implementatieniveau
De volgende best practices op implementatieniveau zorgen voor hoge beschikbaarheid en betrouwbaarheid voor uw AKS-workloads. Deze aanbevolen procedures zijn lokale configuraties die u kunt implementeren in de YAML-bestanden voor uw pods en implementaties.
Notitie
Zorg ervoor dat u deze aanbevolen procedures implementeert telkens wanneer u een update implementeert in uw toepassing. Zo niet, dan ondervindt u mogelijk problemen met de beschikbaarheid en betrouwbaarheid van uw toepassing, zoals onbedoelde uitvaltijd van toepassingen.
Budgetten voor podonderbrekingen (PDBs)
Richtlijnen voor best practices
Gebruik podonderbrekingsbudgetten (PDBs) om ervoor te zorgen dat een minimum aantal pods beschikbaar blijft tijdens vrijwillige onderbrekingen, zoals upgradebewerkingen of onbedoelde verwijderingen van pods.
Met podonderbrekingsbudgetten (PDBs) kunt u definiëren hoe implementaties of replicasets reageren tijdens vrijwillige onderbrekingen, zoals upgradebewerkingen of onbedoelde verwijderingen van pods. Met behulp van PDBs kunt u een minimum- of maximumaantal niet-beschikbare resources definiëren. PDBs zijn alleen van invloed op de verwijderings-API voor vrijwillige onderbrekingen.
Stel dat u een clusterupgrade moet uitvoeren en al een PDB hebt gedefinieerd. Voordat u de clusterupgrade uitvoert, zorgt de Kubernetes-scheduler ervoor dat het minimale aantal pods dat is gedefinieerd in de PDB beschikbaar is. Als de upgrade ertoe zou leiden dat het aantal beschikbare pods onder het minimum valt dat is gedefinieerd in de PDBs, plant de scheduler extra pods op andere knooppunten voordat de upgrade kan worden voortgezet. Als u geen PDB instelt, heeft de planner geen beperkingen voor het aantal pods dat niet beschikbaar kan zijn tijdens de upgrade, wat kan leiden tot een gebrek aan resources en mogelijke clusterstoringen.
In het volgende voorbeeld van een PDB-definitiebestand stelt het minAvailable veld het minimum aantal pods in dat beschikbaar moet blijven tijdens vrijwillige onderbrekingen. De waarde kan een absoluut getal zijn (bijvoorbeeld 3) of een percentage van het gewenste aantal pods (bijvoorbeeld 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
Zie Beschikbaarheid plannen met behulp van PDBs en Een onderbrekingsbudget voor uw toepassing opgeven voor meer informatie.
Cpu- en geheugenlimieten voor pods
Richtlijnen voor best practices
Stel cpu- en geheugenlimieten voor pods in voor alle pods om ervoor te zorgen dat pods niet alle resources op een knooppunt verbruiken en bescherming bieden tijdens servicebedreigingen, zoals DDoS-aanvallen.
Cpu- en geheugenlimieten voor pods definiëren de maximale hoeveelheid CPU en geheugen die een pod kan gebruiken. Wanneer een pod de gedefinieerde limieten overschrijdt, wordt deze gemarkeerd voor verwijdering. Zie CPU-resource-eenheden in Kubernetes en Geheugenresource-eenheden in Kubernetes voor meer informatie.
Door CPU- en geheugenlimieten in te stellen, kunt u de status van knooppunten behouden en de impact op andere pods op het knooppunt minimaliseren. Vermijd het instellen van een podlimiet die hoger is dan uw knooppunten kunnen ondersteunen. Elk AKS-knooppunt reserveert een vaste hoeveelheid CPU en geheugen voor de kubernetes-kernonderdelen. Als u een podlimiet instelt die hoger is dan het knooppunt kan ondersteunen, kan uw toepassing proberen te veel resources te verbruiken en andere pods op het knooppunt negatief beïnvloeden. Clusterbeheerders moeten resourcequota instellen voor een naamruimte waarvoor resourceaanvragen en limieten moeten worden ingesteld. Zie Resourcequota afdwingen in AKS voor meer informatie.
In het volgende voorbeeldbestand voor poddefinities stelt de resources sectie de CPU- en geheugenlimieten voor de pod in:
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
Tip
U kunt de kubectl describe node opdracht gebruiken om de CPU- en geheugencapaciteit van uw knooppunten weer te geven, zoals wordt weergegeven in het volgende voorbeeld:
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
Zie CPU-resources toewijzen aan containers en pods en geheugenresources toewijzen aan containers en pods voor meer informatie.
Haken vooraf stoppen
Richtlijnen voor best practices
Gebruik, indien van toepassing, pre-stop hooks om een container correct te beëindigen.
Een PreStop hook wordt onmiddellijk aangeroepen voordat een container wordt beëindigd vanwege een API-aanvraag of -beheergebeurtenis, zoals voorrang, resourceconflicten of een live-/opstarttestfout. Een aanroep naar de PreStop haak mislukt als de container al een beëindigde of voltooide status heeft en de hook moet worden voltooid voordat het TERM-signaal wordt verzonden om de container te stoppen. Het aftellen van de respijtperiode voor beëindiging van de pod begint voordat de hook wordt uitgevoerd, zodat de PreStop container uiteindelijk wordt beëindigd binnen de respijtperiode voor beëindiging.
In het volgende voorbeeld van een poddefinitiebestand ziet u hoe u een PreStop hook gebruikt om ervoor te zorgen dat een container correct wordt beëindigd:
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"]
Zie Voor meer informatie containerlevenscyclushook en beëindiging van pods.
maxUnavailable
Richtlijnen voor best practices
Definieer het maximum aantal pods dat niet beschikbaar kan zijn tijdens een rolling update met behulp van het
maxUnavailableveld in uw implementatie om ervoor te zorgen dat er een minimum aantal pods beschikbaar blijft tijdens de upgrade.
In maxUnavailable het veld wordt het maximum aantal pods opgegeven dat niet beschikbaar is tijdens het updateproces. De waarde kan een absoluut getal zijn (bijvoorbeeld 3) of een percentage van het gewenste aantal pods (bijvoorbeeld 10%). maxUnavailable heeft betrekking op de Delete-API, die wordt gebruikt tijdens rolling updates.
In het volgende voorbeeldimplementatiemanifest wordt het maxAvailable veld gebruikt om het maximum aantal pods in te stellen dat niet beschikbaar is tijdens het updateproces:
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
Zie Max Niet beschikbaar voor meer informatie.
Beperkingen voor spreiding van podtopologie
Richtlijnen voor best practices
Gebruik beperkingen voor podtopologiespreiding om ervoor te zorgen dat pods worden verdeeld over verschillende knooppunten of zones om de beschikbaarheid en betrouwbaarheid te verbeteren.
U kunt beperkingen voor podtopologiespreiding gebruiken om te bepalen hoe pods over uw cluster worden verdeeld op basis van de topologie van de knooppunten en pods over verschillende knooppunten of zones verdelen om de beschikbaarheid en betrouwbaarheid te verbeteren.
In het volgende voorbeeld van een poddefinitiebestand ziet u hoe u het topologySpreadConstraints veld kunt gebruiken om pods over verschillende knooppunten te verdelen:
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
Zie Beperkingen voor spreiding van podtopologie voor meer informatie.
Gereedheid, leven en opstarttests
Richtlijnen voor best practices
Configureer gereedheids-, leefbaarheids- en opstarttests indien van toepassing om de tolerantie voor hoge belastingen te verbeteren en het opnieuw opstarten van containers te verlagen.
Gereedheidstests
In Kubernetes maakt de kubelet gebruik van gereedheidstests om te weten wanneer een container gereed is om verkeer te accepteren. Een pod wordt als gereed beschouwd wanneer alle containers gereed zijn. Wanneer een pod niet gereed is, wordt deze verwijderd uit de load balancers van de service. Zie Gereedheidstests in Kubernetes voor meer informatie.
In het volgende voorbeeld van een poddefinitiebestand ziet u een configuratie van de gereedheidstest:
readinessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5
Zie Gereedheidstests configureren voor meer informatie.
Liveness-tests
In Kubernetes gebruikt de kubelet liveness-tests om te weten wanneer een container opnieuw moet worden opgestart. Als de livenesstest van een container mislukt, wordt de container opnieuw opgestart. Zie Liveness Probes in Kubernetes voor meer informatie.
In het volgende voorbeeld van een poddefinitiebestand ziet u een livenesstestconfiguratie:
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
Een ander soort livenesstest maakt gebruik van een HTTP GET-aanvraag. In het volgende voorbeeld van een poddefinitiebestand ziet u een configuratie van de HTTP GET-aanvraag livenesstest:
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
Zie Liveness-tests configureren en Een HTTP-aanvraag voor liveness definiëren voor meer informatie.
Opstarttests
In Kubernetes gebruikt de kubelet opstarttests om te weten wanneer een containertoepassing is gestart. Wanneer u een opstarttest configureert, worden gereedheids- en actiefheidstests pas gestart als de opstarttest slaagt, zodat de gereedheids- en livenesstests geen invloed hebben op het opstarten van toepassingen. Zie Opstarttests in Kubernetes voor meer informatie.
In het volgende voorbeeld van een poddefinitiebestand ziet u een configuratie van de opstarttest:
startupProbe:
httpGet:
path: /healthz
port: 8080
failureThreshold: 30
periodSeconds: 10
Toepassingen met meerdere replica's
Richtlijnen voor best practices
Implementeer ten minste twee replica's van uw toepassing om hoge beschikbaarheid en tolerantie in scenario's met knooppunten te garanderen.
In Kubernetes kunt u het replicas veld in uw implementatie gebruiken om het aantal pods op te geven dat u wilt uitvoeren. Door meerdere exemplaren van uw toepassing uit te voeren, kunt u zorgen voor hoge beschikbaarheid en tolerantie in scenario's met knooppunten. Als u beschikbaarheidszones hebt ingeschakeld, kunt u het replicas veld gebruiken om het aantal pods op te geven dat u wilt uitvoeren in meerdere beschikbaarheidszones.
In het volgende voorbeeld van een poddefinitiebestand ziet u hoe u het replicas veld gebruikt om het aantal pods op te geven dat u wilt uitvoeren:
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
Zie Het overzicht van de aanbevolen oplossing voor actieve en actieve hoge beschikbaarheid voor AKS en replica's in implementatiespecificaties voor meer informatie.
Best practices op cluster- en knooppuntgroepniveau
Met de volgende best practices op cluster- en knooppuntgroepniveau kunt u zorgen voor hoge beschikbaarheid en betrouwbaarheid voor uw AKS-clusters. U kunt deze aanbevolen procedures implementeren bij het maken of bijwerken van uw AKS-clusters.
Beschikbaarheidszones
Richtlijnen voor best practices
Gebruik meerdere beschikbaarheidszones bij het maken van een AKS-cluster om hoge beschikbaarheid in zone-down scenario's te garanderen. Houd er rekening mee dat u de configuratie van de beschikbaarheidszone niet kunt wijzigen nadat u het cluster hebt gemaakt.
Beschikbaarheidszones zijn gescheiden groepen datacenters binnen een regio. Deze zones zijn dicht genoeg om verbindingen met lage latentie met elkaar te hebben, maar ver genoeg uit elkaar om de kans te verkleinen dat meer dan één zone wordt beïnvloed door lokale storingen of het weer. Door beschikbaarheidszones te gebruiken, blijft uw gegevens gesynchroniseerd en toegankelijk in zone-downscenario's. Zie Uitvoeren in meerdere zones voor meer informatie.
Automatische schaalaanpassing van clusters
Richtlijnen voor best practices
Gebruik automatische schaalaanpassing van clusters om ervoor te zorgen dat uw cluster een verhoogde belasting kan verwerken en de kosten tijdens lage belasting kan verlagen.
Als u de toepassingsvereisten in AKS wilt bijhouden, moet u mogelijk het aantal knooppunten aanpassen waarop uw workloads worden uitgevoerd. Het onderdeel voor automatische schaalaanpassing van clusters controleert op pods in uw cluster die niet kunnen worden gepland vanwege resourcebeperkingen. Wanneer de automatische schaalaanpassing van clusters problemen detecteert, wordt het aantal knooppunten in de knooppuntgroep opgeschaald om te voldoen aan de vraag van de toepassing. Het controleert ook regelmatig knooppunten op een gebrek aan actieve pods en schaalt zo nodig het aantal knooppunten omlaag. Zie Automatische schaalaanpassing van clusters in AKS voor meer informatie.
U kunt de parameter gebruiken bij het --enable-cluster-autoscaler maken van een AKS-cluster om automatische schaalaanpassing van clusters in te schakelen, zoals wordt weergegeven in het volgende voorbeeld:
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
U kunt de automatische schaalaanpassing van clusters ook inschakelen voor een bestaande knooppuntgroep en gedetailleerdere details van de automatische schaalaanpassing van clusters configureren door de standaardwaarden in het profiel voor automatische schaalaanpassing voor het hele cluster te wijzigen.
Zie De automatische schaalaanpassing van clusters gebruiken in AKS voor meer informatie.
Standard Load Balancer
Richtlijnen voor best practices
Gebruik de Standard Load Balancer om meer betrouwbaarheid en resources te bieden, ondersteuning voor meerdere beschikbaarheidszones, HTTP-tests en functionaliteit in meerdere datacenters.
In Azure is de Standard Load Balancer-SKU ontworpen voor taakverdeling van netwerklaagverkeer wanneer hoge prestaties en lage latentie nodig zijn. De Standard Load Balancer routeert verkeer binnen en tussen regio's en naar beschikbaarheidszones voor hoge tolerantie. De Standard-SKU is de aanbevolen en standaard-SKU die moet worden gebruikt bij het maken van een AKS-cluster.
Belangrijk
Op 30 september 2025 wordt Basic Load Balancer buiten gebruik gesteld. Zie de officiële aankondiging voor meer informatie. U wordt aangeraden de Standard Load Balancer te gebruiken voor nieuwe implementaties en bestaande implementaties bij te werken naar de Standard Load Balancer. Zie Upgraden van Basic Load Balancer voor meer informatie.
In het volgende voorbeeld ziet u een LoadBalancer servicemanifest dat gebruikmaakt van de 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
Zie Een standaard load balancer gebruiken in AKS voor meer informatie.
Tip
U kunt ook een ingangscontroller of een service-mesh gebruiken om netwerkverkeer te beheren, waarbij elke optie verschillende functies en mogelijkheden biedt.
Systeemknooppuntgroepen
Toegewezen systeemknooppuntgroepen gebruiken
Richtlijnen voor best practices
Gebruik systeemknooppuntgroepen om ervoor te zorgen dat er geen andere gebruikerstoepassingen worden uitgevoerd op dezelfde knooppunten, wat kan leiden tot resourcetekort en invloed op systeempods.
Gebruik toegewezen systeemknooppuntgroepen om ervoor te zorgen dat er geen andere gebruikerstoepassing wordt uitgevoerd op dezelfde knooppunten, wat kan leiden tot overschrijding van resources en potentiële clusterstoringen vanwege raceomstandigheden. Als u een toegewezen systeemknooppuntgroep wilt gebruiken, kunt u de CriticalAddonsOnly taint in de systeemknooppuntgroep gebruiken. Zie Systeemknooppuntgroepen gebruiken in AKS voor meer informatie.
Automatisch schalen voor systeemknooppuntgroepen
Richtlijnen voor best practices
Configureer de automatische schaalaanpassing voor systeemknooppuntgroepen om minimum- en maximumschaallimieten in te stellen voor de knooppuntgroep.
Gebruik de automatische schaalaanpassing voor knooppuntgroepen om de minimum- en maximumschaallimieten voor de knooppuntgroep te configureren. De systeemknooppuntgroep moet altijd kunnen worden geschaald om te voldoen aan de vereisten van systeempods. Als de systeemknooppuntgroep niet kan worden geschaald, heeft het cluster onvoldoende resources om planning, schaalaanpassing en taakverdeling te beheren, wat kan leiden tot een niet-reagerend cluster.
Zie De automatische schaalaanpassing van clusters gebruiken voor knooppuntgroepen voor meer informatie.
Ten minste drie knooppunten per systeemknooppuntgroep
Richtlijnen voor best practices
Zorg ervoor dat systeemknooppuntgroepen ten minste drie knooppunten hebben om tolerantie te garanderen tegen blokkeren/upgradescenario's, wat kan leiden tot het opnieuw opstarten van knooppunten of het afsluiten van knooppunten.
Systeemknooppuntgroepen worden gebruikt voor het uitvoeren van systeempods, zoals de kube-proxy, coredns en de Azure CNI-invoegtoepassing. We raden u aan ervoor te zorgen dat systeemknooppuntgroepen ten minste drie knooppunten hebben om tolerantie te garanderen tegen blokkeren/upgradescenario's, waardoor knooppunten opnieuw worden opgestart of afgesloten. Zie Systeemknooppuntgroepen beheren in AKS voor meer informatie.
Versneld netwerken
Richtlijnen voor best practices
Gebruik versneld netwerken om lagere latentie, verminderde jitter en minder CPU-gebruik op uw VM's te bieden.
Versneld netwerken maakt I/O-virtualisatie met één hoofdmap (SR-IOV) mogelijk voor ondersteunde VM-typen, waardoor de netwerkprestaties aanzienlijk worden verbeterd.
In het volgende diagram ziet u hoe twee VM's communiceren met en zonder versneld netwerken:
Zie overzicht van versneld netwerken voor meer informatie.
Installatiekopieversies
Richtlijnen voor best practices
Afbeeldingen mogen de
latesttag niet gebruiken.
Tags voor containerinstallatiekopieën
Het gebruik van de latest tag voor containerinstallatiekopieën kan leiden tot onvoorspelbaar gedrag en maakt het lastig om bij te houden welke versie van de installatiekopieën wordt uitgevoerd in uw cluster. U kunt deze risico's minimaliseren door tijdens de build en runtime scan- en herstelprogramma's in uw containers te integreren en uit te voeren. Zie Best practices voor containerinstallatiekopieën beheren in AKS voor meer informatie.
Upgrades van knooppuntinstallatiekopieën
AKS biedt meerdere kanalen voor automatische upgrade voor upgrades van installatiekopieën van knooppuntbesturingssysteem. U kunt deze kanalen gebruiken om de timing van upgrades te beheren. U wordt aangeraden deel te nemen aan deze kanalen voor automatische upgrade om ervoor te zorgen dat uw knooppunten de meest recente beveiligingspatches en updates uitvoeren. Zie Installatiekopieën van knooppuntbesturingssysteem automatisch upgraden in AKS voor meer informatie.
Standard-laag voor productieworkloads
Richtlijnen voor best practices
Gebruik de Standard-laag voor productworkloads voor meer betrouwbaarheid en resources van clusters, ondersteuning voor maximaal 5000 knooppunten in een cluster en sla voor uptime standaard ingeschakeld. Als u LTS nodig hebt, kunt u overwegen om de Premium-laag te gebruiken.
De Standard-laag voor Azure Kubernetes Service (AKS) biedt een sla (Service Level Agreement) met een financiële ondersteuning van 99,9% voor uw productieworkloads. De standard-laag biedt ook meer betrouwbaarheid en resources voor clusters, ondersteuning voor maximaal 5000 knooppunten in een cluster en sla voor uptime standaard ingeschakeld. Zie Prijscategorieën voor AKS-clusterbeheer voor meer informatie.
Azure CNI voor dynamische IP-toewijzing
Richtlijnen voor best practices
Configureer Azure CNI voor dynamische IP-toewijzing voor beter IP-gebruik en om IP-uitputting voor AKS-clusters te voorkomen.
Met de dynamische IP-toewijzingsmogelijkheid in Azure CNI worden pod-IP-adressen toegewezen van een subnet gescheiden van het subnet dat als host fungeert voor het AKS-cluster en biedt de volgende voordelen:
- Beter IP-gebruik: IP-adressen worden dynamisch toegewezen aan clusterpods vanuit het subnet Pods. Dit leidt tot een beter gebruik van IP-adressen in het cluster in vergelijking met de traditionele CNI-oplossing, die statische toewijzing van IP-adressen voor elk knooppunt uitvoert.
- Schaalbaar en flexibel: subnetten van knooppunten en pods kunnen onafhankelijk worden geschaald. Eén podsubnet kan worden gedeeld over meerdere knooppuntgroepen van een cluster of over meerdere AKS-clusters die in hetzelfde VNet zijn geïmplementeerd. U kunt ook een afzonderlijk podsubnet configureren voor een knooppuntgroep.
- Hoge prestaties: omdat pod IP's van virtuele netwerken worden toegewezen, hebben ze directe connectiviteit met andere clusterpods en resources in het VNet. De oplossing ondersteunt zeer grote clusters zonder dat de prestaties afnemen.
- Afzonderlijk VNet-beleid voor pods: aangezien pods een afzonderlijk subnet hebben, kunt u afzonderlijke VNet-beleidsregels configureren die afwijken van knooppuntbeleid. Dit maakt veel nuttige scenario's mogelijk, zoals het toestaan van internetverbinding alleen voor pods en niet voor knooppunten, het herstellen van het bron-IP-adres voor pods in een knooppuntgroep met behulp van een Azure NAT-gateway en het gebruik van NSG's om verkeer tussen knooppuntgroepen te filteren.
- Kubernetes-netwerkbeleid: zowel het Azure-netwerkbeleid als Calico werken met deze oplossing.
Zie Azure CNI-netwerken configureren voor dynamische toewijzing van IP-adressen en verbeterde subnetondersteuning voor meer informatie.
V5 SKU-VM's
Richtlijnen voor best practices
Gebruik v5 VM-SKU's voor verbeterde prestaties tijdens en na updates, minder algemene impact en een betrouwbaardere verbinding voor uw toepassingen.
Voor knooppuntgroepen in AKS gebruikt u V5 SKU-VM's met tijdelijke besturingssysteemschijven om voldoende rekenresources te bieden voor kube-systeempods. Zie Best practices voor prestaties en het schalen van grote workloads in AKS voor meer informatie.
Vm's uit de B-serie niet gebruiken
Richtlijnen voor best practices
Gebruik geen vm's uit de B-serie voor AKS-clusters omdat ze lage prestaties hebben en niet goed werken met AKS.
VM's uit de B-serie zijn slecht en werken niet goed met AKS. In plaats daarvan raden we u aan v5 SKU-VM's te gebruiken.
Premium-schijven
Richtlijnen voor best practices
Gebruik Premium-schijven om een beschikbaarheid van 99,9% in één virtuele machine (VM) te bereiken.
Azure Premium Disks bieden een consistente schijflatentie van submilliseconden en hoge IOPS en overal. Premium-schijven zijn ontworpen voor lage latentie, hoge prestaties en consistente schijfprestaties voor VM's.
In het volgende voorbeeld van het YAML-manifest ziet u een definitie van de opslagklasse voor een Premium-schijf:
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
Zie Azure Premium SSD v2-schijven op AKS gebruiken voor meer informatie.
Container Insights
Richtlijnen voor best practices
Schakel Container Insights in om de prestaties van uw containertoepassingen te bewaken en diagnosticeren.
Container Insights is een functie van Azure Monitor waarmee containerlogboeken van AKS worden verzameld en geanalyseerd. U kunt de verzamelde gegevens analyseren met een verzameling weergaven en vooraf gemaakte werkmappen.
U kunt Container Insights-bewaking inschakelen op uw AKS-cluster met behulp van verschillende methoden. In het volgende voorbeeld ziet u hoe u Container Insights-bewaking inschakelt op een bestaand cluster met behulp van de Azure CLI:
az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup
Zie Bewaking inschakelen voor Kubernetes-clusters voor meer informatie.
Azure Policy
Richtlijnen voor best practices
Beveiligings- en nalevingsvereisten toepassen en afdwingen voor uw AKS-clusters met behulp van Azure Policy.
U kunt ingebouwd beveiligingsbeleid toepassen en afdwingen op uw AKS-clusters met behulp van Azure Policy. Azure Policy helpt bij het afdwingen van organisatiestandaarden en het beoordelen van naleving op schaal. Nadat u de Azure Policy-invoegtoepassing voor AKS hebt geïnstalleerd, kunt u afzonderlijke beleidsdefinities of groepen beleidsdefinities toepassen die initiatieven voor uw clusters worden genoemd.
Zie Uw AKS-clusters beveiligen met Azure Policy voor meer informatie.
Volgende stappen
Dit artikel is gericht op aanbevolen procedures voor implementatie en clusterbetrouwbaarheid voor AKS-clusters (Azure Kubernetes Service). Zie de volgende artikelen voor meer aanbevolen procedures:
Azure Kubernetes Service