Best practices voor implementatie en clusterbetrouwbaarheid voor Azure Kubernetes Service (AKS)

Van toepassing op: ✔️ AKS Automatic ✔️ AKS Standard

Betrouwbaarheid van AKS-clusters verwijst naar de mogelijkheid van een Azure Kubernetes Service cluster om beschikbaarheid te behouden, te herstellen van storingen en onderbrekingen met minimale downtime af te handelen. Dit artikel bevat aanbevolen procedures voor de betrouwbaarheid van clusters die zijn geïmplementeerd op implementatie- en clusterniveau voor uw Azure Kubernetes Service (AKS) workloads. Het artikel is bedoeld voor clusteroperators en ontwikkelaars die verantwoordelijk zijn voor het implementeren en beheren van toepassingen in AKS.

Belangrijke punten

• Stel CPU- en geheugenlimieten in voor alle pods om uitputting van resources te voorkomen en bescherming te bieden tegen servicebedreigingen, zoals DDoS-aanvallen.
• Gebruik Pod Disruption Budgets (PDB's) om de minimale beschikbaarheid van pods te waarborgen tijdens vrijwillige verstoringen, zoals upgrades of onbedoelde verwijderingen.
• Schakel beschikbaarheidszones in tijdens het maken van het cluster om hoge beschikbaarheid in zone-down scenario's te garanderen (kan niet worden gewijzigd na het maken).
• Implementeer ten minste twee replica's van uw toepassing om hoge beschikbaarheid en tolerantie in scenario's met knooppunten te garanderen.
• Configureer gereedheids-, liveness- en opstartprobes om de veerkracht van applicaties te verbeteren en onnodige containerherstarts te verminderen.
• Gebruik Standard Load Balancer voor productieworkloads ter ondersteuning van meerdere beschikbaarheidszones en hoge tolerantie.
• Schakel Container Insights in om de prestaties van uw containertoepassingen te bewaken en diagnosticeren.

Dit artikel bevat aanbevolen procedures voor de betrouwbaarheid van clusters die zijn geïmplementeerd op implementatie- en clusterniveau voor uw Azure Kubernetes Service (AKS) workloads. 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:

AKS-clustermodi en -betrouwbaarheid

AKS ondersteunt twee clustermodi: AKS Automatic en AKS Standard. Veel betrouwbaarheidspraktijken op workloadniveau zijn in gelijke mate van toepassing op beide modi, zoals het instellen van resourceverzoeken, het definiëren van Pod Disruption Budgets (PDB's), het configureren van probes en het draaien van meerdere replica's. De verantwoordelijkheden op clusterniveau verschillen echter per modus:

• AKS Automatic biedt meer vooraf geconfigureerde betrouwbaarheidsstandaarden, waaronder pools voor beheerde systeemknooppunten, automatisch inrichten van knooppunten (NAP), automatische clusterupgrades, automatische upgrades van knooppuntbesturingssysteeminstallatiekopieën, Standard-laag en LocalDNS.
• AKS Standard biedt een breder direct configuratiebeheer en vereist dat operators expliciet meer betrouwbaarheidsfuncties op clusterniveau inschakelen en beheren.

Voor meer informatie, zie Wat is AKS Automatic?

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.

Controlelijst voor snelzoekgids:

• PDBs configureren voor alle productieworkloads
• CPU- en geheugenlimieten instellen voor alle pods
• Ten minste 2 replica's implementeren voor zone-tolerante workloads
• Gereedheids-, actiefheids- en opstarttests configureren voor alle containers
• Beperkingen voor spreiding van podtopologie gebruiken voor kritieke toepassingen

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 gezondheid van het knooppunt 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.

Clusterbeheerders kunnen deze instellingen ook versterken met quota op naamruimteniveau en beleidsbesturingselementen. In AKS Automatic kunnen implementatiebeveiligingen helpen om resourcegerelateerde best practices af te dwingen, maar operators moeten nog steeds expliciet resourceaanvragen en -limieten definiëren die passen bij de workload. 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

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.

Verticale Pod Autoscaler (VPA)

Richtlijnen voor best practices

Gebruik Verticale Pod Autoscaler (VPA) om automatisch CPU- en geheugenaanvragen voor uw pods aan te passen op basis van hun werkelijke gebruik.

Hoewel deze niet rechtstreeks wordt geïmplementeerd via het pod YAML-bestand, helpt de Verticale Pod Autoscaler bij het optimaliseren van de toewijzing van resources door automatisch de CPU- en geheugenaanvragen voor uw pods aan te passen. Dit zorgt ervoor dat uw toepassingen de benodigde middelen hebben om efficiënt te draaien zonder overprovisionering of onderprovisionering.

In AKS Automatic is VPA standaard ingeschakeld op het cluster. In AKS Standard kiezen operators of ze dit inschakelen.

VPA werkt in drie modi:

• Uit: Geeft alleen aanbevelingen zonder wijzigingen door te voeren.
• Automatisch: Werkt automatisch bij en past podresourceaanvragen aan tijdens het opnieuw opstarten van pods.
• Initial: hiermee stelt u alleen resourceaanvragen in tijdens het maken van de pod.

In het volgende voorbeeld ziet u hoe u een VPA-resource configureert in Kubernetes:

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

Zie de documentatie voor Automatische schaalaanpassing van verticale pods voor meer informatie.

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. PDB's beïnvloeden alleen de Eviction API bij 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.

Upgradeautomatisering op clusterniveau in AKS Automatisch vermindert een aantal operationele lasten, maar de beschikbaarheid van workloads tijdens onderbrekingen is nog steeds afhankelijk van besturingselementen op toepassingsniveau, zoals PDBs.

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.

Zie Automatisch PDB-beheer voor AKS (preview) als u het maken van PDB voor niet-beveiligde implementaties wilt automatiseren en pDB-gerelateerde afvoerfouten tijdens upgrades wilt voorkomen.

Respijtelijke beëindiging voor pods

Richtlijnen voor best practices

Gebruik PreStop hooks en configureer een geschikte terminationGracePeriodSeconds waarde om ervoor te zorgen dat pods correct worden beëindigd.

Een goede beëindiging zorgt ervoor dat pods voldoende tijd krijgen om resources op te schonen, lopende taken te voltooien of afhankelijke services op de hoogte te stellen voordat ze worden beëindigd. Dit is met name belangrijk voor stateful toepassingen of services waarvoor de juiste afsluitprocedures zijn vereist.

Gebruik maken van PreStop hooks

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. Met PreStop de hook kunt u aangepaste opdrachten of scripts definiëren die moeten worden uitgevoerd voordat de container wordt gestopt. U kunt deze bijvoorbeeld gebruiken om logboeken leeg te maken, databaseverbindingen te sluiten of andere services op de hoogte te stellen van het afsluiten.

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:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "nginx -s quit; while killall -0 nginx; do sleep 1; done"]

Configureren terminationGracePeriodSeconds

Het terminationGracePeriodSeconds veld geeft de hoeveelheid tijd aan die Kubernetes wacht voordat een pod geforceerd wordt beëindigd. Deze periode omvat de tijd die nodig is om de PreStop haak uit te voeren. Als de PreStop hook niet binnen de gratieperiode is voltooid, wordt de pod gedwongen beëindigd.

Met de volgende poddefinitie wordt bijvoorbeeld een afsluitperiode van 30 seconden ingesteld.

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

Voor meer informatie, zie containerlevenscyclus-hooks en Beëindiging van Pods.

Hoge beschikbaarheid tijdens upgrades

Gebruiken maxSurge voor snellere updates

Richtlijnen voor best practices

Configureer het maxSurge veld zodat extra pods kunnen worden gemaakt tijdens rolling updates, waardoor snellere updates met minimale downtime mogelijk zijn.

In het veld maxSurge wordt het maximumaantal extra pods opgegeven dat kan worden aangemaakt bovenop het gewenste aantal pods tijdens een rolling update. Hierdoor kunnen nieuwe pods worden gemaakt en gereed worden voordat oude pods worden beëindigd, waardoor snellere updates worden gegarandeerd en het risico op downtime wordt verminderd.

In het volgende voorbeeldimplementatiemanifest ziet u hoe u het configureert maxSurge:

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

Door deze configuratie in te stellen op maxSurge 3, zorgt u ervoor dat maximaal drie extra pods kunnen worden gemaakt tijdens de rolling update, waardoor het implementatieproces wordt versneld terwijl de beschikbaarheid van uw toepassing behouden blijft. Zie Rolling Updates in Kubernetes voor meer informatie.

Gebruiken maxUnavailable voor gecontroleerde updates

Richtlijnen voor best practices

Configureer het maxUnavailable veld om het aantal pods te beperken dat niet beschikbaar kan zijn tijdens rolling updates, zodat uw toepassing operationeel blijft met minimale onderbrekingen.

Het maxUnavailable veld is met name nuttig voor toepassingen die rekenintensief zijn of specifieke infrastructuurbehoeften hebben. Hiermee geeft u het maximum aantal pods op dat op elk gewenst moment niet beschikbaar kan zijn tijdens een rolling update. Dit zorgt ervoor dat een deel van uw toepassing functioneel blijft terwijl nieuwe pods worden geïmplementeerd en oude worden beëindigd.

U kunt instellen maxUnavailable als een absoluut getal (bijvoorbeeld 1) of een percentage van het gewenste aantal pods (bijvoorbeeld 25%). Als uw toepassing bijvoorbeeld vier replica's heeft en u instelt op maxUnavailable1, zorgt Kubernetes ervoor dat ten minste drie pods beschikbaar blijven tijdens het updateproces.

In het volgende voorbeeldimplementatiemanifest ziet u hoe u het configureert maxUnavailable:

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 dit voorbeeld zorgt de instelling van maxUnavailable naar 1 ervoor dat op een gegeven moment tijdens de rolling update niet meer dan één pod niet beschikbaar is. Deze configuratie is ideaal voor toepassingen die gespecialiseerde berekeningen vereisen, waarbij het handhaven van een minimumniveau van service beschikbaarheid essentieel is.

Zie Rolling Updates in Kubernetes 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 AKS Automatic kunnen implementatiebeveiligingen helpen bij het toepassen van best practices voor workloaddistributie, maar toepassingsspecifieke topologievereisten moeten nog steeds expliciet worden gedefinieerd in workloadmanifesten.

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

Raadpleeg Pod Topologie Spreidingsbeperkingen voor meer informatie.

Gereedheids-, levendigheids- en opstartcontroles

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.

Zelfs wanneer AKS Automatic basislijnbeveiliging biedt, blijft de testconfiguratie workloadspecifiek en moet deze nog steeds worden geschreven in toepassingsmanifesten.

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 uit de serviceload balancers verwijderd. 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-probes

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 wordt een livenessprobeconfiguratie weergegeven.

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

Een ander soort livenesstest maakt gebruik van een HTTP GET-aanvraag. In het volgende voorbeeld van een pod-definitiebestand ziet u een configuratie van de HTTP GET-verzoek livenessprobe.

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 voor meer informatie levendigheidscontroles configureren en een HTTP-verzoek voor levendigheid definiëren.

Opstartsondes

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 startup probe.

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 een hoge beschikbaarheid en veerkracht te garanderen in scenario's waarin knooppunten uitvallen.

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 veerkracht in situaties waarin knooppunten uitvallen. AKS Automatic verbetert de operationele gereedheid en het schaalgedrag, maar beschikbaarheid is nog steeds afhankelijk van het uitvoeren van voldoende replica's en het gebruik van de juiste plaatsingsregelaars. Als je beschikbaarheidszones hebt ingeschakeld, kun je het replicas gebruiken om het aantal pods op te geven dat je wilt laten draaien 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 voor meer informatie het overzicht van de aanbevolen actieve-actieve hoge beschikbaarheidsoplossing voor AKS en replica's in implementatiespecificaties.

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. In vergelijking met instellingen op implementatieniveau verschilt de verantwoordelijkheid aanzienlijk tussen AKS Automatic en AKS Standard.

Controlelijst voor snelzoekgids:

• Beschikbaarheidszones inschakelen bij het maken van clusters (3 aanbevolen beschikbaarheidszones)
• Gebruik Standard Load Balancer voor alle productieworkloads
• Minimaal 2 knooppunten per systeemknooppuntgroep configureren
• Container Insights inschakelen voor bewaking
• Prijscategorie Standard of Premium gebruiken voor productie

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.

AKS Automatic vereenvoudigt dag-2-bewerkingen, maar hiermee hoeft u geen topologie te plannen tijdens het maken van clusters waarbij zonegebonden implementatie deel uitmaakt van het ontwerp.

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.

Schaalgedrag verschilt per clustermodus:

• Automatisch AKS: automatische inrichting van knooppunten is vooraf geconfigureerd en functies voor het schalen van werkbelastingen, zoals HPA, KEDA en VPA, zijn standaard ingeschakeld.
• AKS Standard: Operators schakelen de cluster-autoscaler, automatische inrichting van nodes en functies voor het automatisch schalen van workloads expliciet in en stemmen deze af.

Voor AKS Standard kunt u de parameter --enable-cluster-autoscaler gebruiken bij het maken van een cluster:

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.

Betrouwbaarheid van inkomend en uitgaand verkeer

Richtlijnen voor best practices

Gebruik het clusternetwerkmodel dat overeenkomt met de AKS-clustermodus en betrouwbaarheidsvereisten.

Voor AKS Standard blijft Standard Load Balancer een algemene en aanbevolen betrouwbaarheidskeuze voor inkomende en uitgaande verkeersscenario's.

Voor AKS Automatic worden de standaardinstellingen voor inkomend en uitgaand verkeer centraler beheerd:

• Beheerd virtueel netwerk is standaard vooraf geconfigureerd.
• Beheerde NAT-gateway is vooraf geconfigureerd voor ondersteunde scenario's voor beheerde virtuele netwerken.
• Beheerd inkomend verkeer via toepassingsroutering is vooraf geconfigureerd voor ondersteunde clusterversies.

Als u AKS Standard gebruikt, zijn de volgende Standard Load Balancer richtlijnen nog steeds van toepassing:

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.

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.

Systeemknooppuntgroepen

Toegewezen systeemknooppuntgroepen gebruiken

AKS Automatic maakt gebruik van pools voor beheerde systeemknooppunten die worden gemaakt, geschaald, bijgewerkt en beheerd door AKS. De focus van de operator verschuift van het handmatig opbouwen van de topologie van de systeempool naar het valideren van de plaatsing van workloads, capaciteitsgedrag en besturing op naamruimteniveau.

De volgende richtlijnen zijn nog steeds van toepassing op AKS Standard:

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.

In AKS Automatic wordt de capaciteit van de systeemknooppuntgroep beheerd door AKS. Gebruik in AKS Standard de configuratie van automatische schaalaanpassing, zodat de systeemknooppuntgroep altijd kan worden geschaald om te voldoen aan de behoeften van systeempods.

Gebruik de automatische schaalaanpassing voor knooppuntgroepen om de minimum- en maximumschaallimieten voor de knooppuntgroep te configureren. De systeempool voor knooppunten moet altijd kunnen worden geschaald om te voldoen aan de behoeften 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 twee knooppunten per systeemknooppuntgroep

Richtlijnen voor best practices

Zorg ervoor dat systeemknooppuntgroepen ten minste twee knooppunten hebben om tolerantie te garanderen tegen blokkeren/upgradescenario's, wat kan leiden tot het opnieuw opstarten of afsluiten van knooppunten.

In AKS Standard moeten systeemknooppuntgroepen ten minste twee knooppunten hebben om de tolerantie tijdens het opnieuw opstarten of upgrade-gebeurtenissen te verbeteren. In AKS Automatic wordt de tolerantie van systeemknooppuntgroepen beheerd door de service, maar bij het ontwerp van de werkbelasting moet er nog steeds van worden uitgegaan dat systeemonderdelen kunnen worden bijgewerkt of verplaatst als onderdeel van platformbewerkingen.

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 twee 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.

Upgradeconfiguraties voor knooppuntgroepen

Het eigendom van de upgrade verschilt per clustermodus:

• AKS Automatisch: Clusterupgrades maken standaard gebruik van het stabiele kanaal en upgrades van installatiekopieën van knooppuntbesturingssystemen maken standaard gebruik van het NodeImage-kanaal. De focus van operators ligt op gereedheid van workloads, beheersmaatregelen bij verstoringen, onderhoudsschema's en validatie van een veilige uitrol.
• AKS Standard: Operators configureren expliciet upgradekanalen en instellingen voor knooppuntgroepen, zoals maxSurge en maxUnavailable.

Gebruiken maxSurge voor upgrades van knooppuntgroepen

Richtlijnen voor best practices

Configureer de maxSurge instelling voor upgrades van knooppuntgroepen om de betrouwbaarheid te verbeteren en downtime tijdens upgradebewerkingen te minimaliseren.

De maxSurge instelling geeft het maximum aantal extra knooppunten op dat tijdens een upgrade kan worden gemaakt. Dit zorgt ervoor dat nieuwe knooppunten worden ingericht en gereed zijn voordat oude knooppunten worden verwijderd en verwijderd, waardoor het risico op uitvaltijd van toepassingen wordt verminderd.

Met de volgende Azure CLI opdracht wordt bijvoorbeeld maxSurge ingesteld op 1 voor een knooppuntgroep:

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

Door deze te maxSurgeconfigureren, kunt u ervoor zorgen dat upgrades sneller worden uitgevoerd terwijl de beschikbaarheid van toepassingen behouden blijft.

Zie Upgrade van knooppuntgroepen in AKS voor meer informatie.

Gebruiken maxUnavailable voor upgrades van knooppuntgroepen

Richtlijnen voor best practices

Configureer de maxUnavailable instelling voor upgrades van knooppuntgroepen om de beschikbaarheid van toepassingen tijdens upgradebewerkingen te garanderen.

De maxUnavailable instelling geeft het maximum aantal knooppunten op dat tijdens een upgrade niet beschikbaar kan zijn. Dit zorgt ervoor dat een deel van uw knooppuntgroep operationeel blijft terwijl knooppunten worden bijgewerkt.

Met de volgende Azure CLI opdracht wordt bijvoorbeeld maxUnavailable ingesteld op 1 voor een knooppuntgroep:

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

Door deze te maxUnavailableconfigureren, kunt u de impact van upgrades op uw workloads beheren, zodat er tijdens het proces voldoende resources beschikbaar blijven.

Zie Upgrade van knooppuntgroepen 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.

Afbeeldingsversies

Richtlijnen voor best practices

Afbeeldingen mogen de latest tag niet gebruiken.

Tags voor containerafbeeldingen

Het gebruik van de latest-tag voor containerafbeeldingen kan leiden tot onvoorspelbaar gedrag en maakt het moeilijk om bij te houden welke versie van de afbeelding in uw cluster wordt uitgevoerd. 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 voor meer informatie Best practices voor het beheren van containerafbeeldingen in AKS.

Upgrades van knooppuntafbeeldingen

Het upgradegedrag van node-images verschilt per clustermodus:

• AKS Automatic: upgrades van OS-installatiekopieën van knooppunten zijn vooraf geconfigureerd via het NodeImage-kanaal.
• AKS Standard: Operators kiezen voor handmatig beheer of een kanaal voor automatische upgrade.

AKS biedt verschillende automatische upgradekanalen voor upgrades van node-besturingssysteemafbeeldingen. 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 voor meer informatie Het automatisch upgraden van knooppunt-OS-afbeeldingen in AKS.

Standaardprijscategorie voor productieworkloads

Richtlijnen voor best practices

Gebruik de prijscategorie Standard voor productieworkloads voor meer clusterbetrouwbaarheid en -resources, ondersteuning voor maximaal 5.000 knooppunten in een cluster en een standaard ingeschakelde uptime-SLA. Als u LTS nodig hebt, kunt u overwegen om de Premium-laag te gebruiken.

Het Standaardniveau voor Azure Kubernetes Service (AKS) biedt een financieel ondersteund 99,9% uptime SLA (Service Level Agreement) voor uw productie-workloads. De standaardlaag biedt ook meer betrouwbaarheid van clusters en resources, ondersteuning voor maximaal 5000 knooppunten in een cluster, en de Uptime SLA is standaard ingeschakeld. Zie Prijscategorieën voor AKS-clusterbeheer voor meer informatie.

Opmerking over clustermodus:

• AKS Automatic is vooraf geconfigureerd met de Standard-laag, de uptime-SLA en de podgereedheids-SLA.
• AKS Standard wordt standaard ingesteld op de gratis laag, tenzij u expliciet Standard of Premium kiest.

LocalDNS voor DNS-betrouwbaarheid

Richtlijnen voor best practices

Schakel LocalDNS in uw knooppuntgroepen in om de betrouwbaarheid van DNS-resolutie te verbeteren en serviceconnectiviteit te behouden tijdens tijdelijke DNS-storingen.

LocalDNS implementeert een DNS-proxy op elk AKS-knooppunt, met een lage latentie en tolerante DNS-omzetting. Door query's lokaal op te lossen, vermindert conntrack LocalDNS uw afhankelijkheid van gecentraliseerde CoreDNS-pods en voorkomt u tabeluitputting. Dit is een veelvoorkomende oorzaak van verwijderde DNS-query's in omgevingen met hoge doorvoer. LocalDNS biedt ook ondersteuning voor het serveren van verouderde cache-antwoorden gedurende een instelbare periode wanneer upstream DNS-servers niet beschikbaar zijn, waardoor de podconnectiviteit tijdens onderbrekingen behouden blijft. Zie LocalDNS configureren in AKS voor configuratie-instructies en aanbevolen procedures.

Opmerking over clustermodus:

• AKS Automatisch: LocalDNS is vooraf geconfigureerd.
• AKS Standard: LocalDNS is optioneel en moet expliciet worden ingeschakeld.

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.

Voor AKS Standard helpt Azure dynamische IP-toewijzing van CNI het IP-gebruik te verbeteren en IP-uitputting te voorkomen. Voor AKS Automatic wordt het standaardnetwerkpad beheerd met behulp van Azure CNI-overlay, mogelijk gemaakt door Cilium, met optionele aangepaste virtuele netwerkconfiguraties in ondersteunde scenario's.

De mogelijkheid voor dynamische IP-toewijzing in Azure CNI wijst pod-IP-adressen toe vanuit een subnet dat losstaat 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 pods ip-adressen van virtuele netwerken krijgen 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: de Azure netwerkbeleid en Calico werken met deze oplossing.

Zie Configure Azure CNI-netwerken configureren voor dynamische toewijzing van IP-adressen en verbeterde subnetondersteuning voor meer informatie.

v5 SKU-VMs

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.

Gebruik geen VM's uit de B-serie

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 hebben lage prestaties en werken niet goed met AKS. In plaats daarvan raden we u aan v5 SKU-VM's te gebruiken.

Azure Premium SSD

Richtlijnen voor best practices

Gebruik Premium SSD's om een beschikbaarheid van 99,9% in één virtuele machine (VM) te bereiken.

Azure Premium SSD beheerde schijven bieden een consistente schijflatentie van submilliseconden en hoge IOPS en doorvoer. Premium SSD's 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 Gebruik Azure Premium SSD v2-schijven op AKS 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.

Opmerking over clustermodus:

• AKS Automatic: Container Insights is standaard ingeschakeld in ondersteunde maakstromen in Azure CLI en Azure Portal.
• AKS Standard: Container Insights is optioneel en expliciet ingeschakeld.

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 AKS Standard-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 invoegtoepassing Azure Policy voor AKS hebt geïnstalleerd, kunt u afzonderlijke beleidsdefinities of groepen beleidsdefinities, zogenaamde initiatieven, toepassen op uw clusters.

Opmerking over clustermodus:

• AKS Automatisch: Implementatiebeveiligingen en basisbeveiligingsstandaarden voor pods zijn vooraf geconfigureerd in de afdwingingsmodus.
• AKS Standard: Azure Policy en implementatiebeveiligingen zijn optioneel en vereisen expliciete configuratie.

Zie Uw AKS-clusters beveiligen met Azure Policy voor meer informatie.

Verwante inhoud

Dit artikel is gericht op aanbevolen procedures voor implementatie en clusterbetrouwbaarheid voor Azure Kubernetes Service (AKS) clusters. Zie de volgende artikelen voor meer informatie over verwante onderwerpen:

• Wat is AKS Automatic?
• Overzicht van hoge beschikbaarheid en herstel na noodgevallen voor AKS
• AKS-clusters op schaal uitvoeren
• Basislijnarchitectuur voor een AKS-cluster