Basisconcepten van Kubernetes voor Azure Kubernetes Service

De ontwikkeling van toepassingen blijft zich verder ontwikkelen naar een op containers gebaseerde benadering, waardoor we resources moeten organiseren en beheren. Als toonaangevende platform biedt Kubernetes een betrouwbare planning van fouttolerante toepassingsworkloads. Azure Kubernetes Service (AKS), een beheerde Kubernetes-aanbieding, vereenvoudigt de implementatie en het beheer van toepassingen op basis van containers verder.

In dit artikel worden de belangrijkste concepten geïntroduceerd:

• Onderdelen van de Kubernetes-infrastructuur:

  • besturingsvlak
  • Knooppunten
  • knooppuntgroepen

• Workloadresources:

  • Peulen
  • Implementaties
  • Ingesteld

• Resources groeperen met behulp van naamruimten.

Wat is Kubernetes?

Kubernetes is een snel evoluerend platform dat containertoepassingen en de bijbehorende netwerk- en opslagonderdelen beheert. Kubernetes richt zich op de toepassingsworkloads, niet op de onderliggende infrastructuuronderdelen. Kubernetes biedt een declaratieve benadering van implementaties, ondersteund door een robuuste set API's voor beheerbewerkingen.

U kunt moderne, draagbare, op microservices gebaseerde toepassingen bouwen en uitvoeren met behulp van Kubernetes om de beschikbaarheid van de toepassingsonderdelen te organiseren en te beheren. Kubernetes ondersteunt zowel stateless als stateful toepassingen wanneer teams vooruitgang boeken door de acceptatie van op microservices gebaseerde toepassingen.

Als open platform kunt u met Kubernetes uw toepassingen bouwen met uw favoriete programmeertaal, besturingssysteem, bibliotheken of berichtenbus. Bestaande HULPPROGRAMMA's voor continue integratie en continue levering (CI/CD) kunnen worden geïntegreerd met Kubernetes om releases te plannen en te implementeren.

AKS biedt een beheerde Kubernetes-service die de complexiteit van implementatie- en kernbeheertaken vermindert, zoals upgradecoördinatie. Het Azure-platform beheert het AKS-besturingsvlak en u betaalt alleen voor de AKS-knooppunten waarop uw toepassingen worden uitgevoerd.

Kubernetes-clusterarchitectuur

Een Kubernetes-cluster bestaat uit twee onderdelen:

• Besturingsvlak: biedt de belangrijkste Kubernetes-services en indeling van toepassingsworkloads.
• Knooppunten: voer uw toepassingsworkloads uit.

Besturingsvlak

Wanneer u een AKS-cluster maakt, wordt er automatisch een besturingsvlak gemaakt en geconfigureerd. Dit besturingsvlak wordt gratis aangeboden als een beheerde Azure-resource die is geabstraheerd van de gebruiker. U betaalt alleen voor de knooppunten die aan het AKS-cluster zijn gekoppeld. Het besturingsvlak en de bijbehorende resources bevinden zich alleen in de regio waarin u het cluster hebt gemaakt.

Het besturingsvlak bevat de volgende kubernetes-kernonderdelen:

Onderdeel	Beschrijving
kube-apiserver	De API-server is hoe de onderliggende Kubernetes-API's worden weergegeven. Dit onderdeel biedt de interactie voor beheerhulpprogramma's, zoals kubectl of het Kubernetes-dashboard.
etcd	Om de status van uw Kubernetes-cluster en -configuratie te behouden, is de maximaal beschikbare etcd een sleutelwaardearchief in Kubernetes.
kube-scheduler	Wanneer u toepassingen maakt of schaalt, bepaalt de Scheduler welke knooppunten de workload kunnen uitvoeren en starten.
kube-controller-manager	Controllerbeheer houdt toezicht op een aantal kleinere controllers die acties uitvoeren, zoals het repliceren van pods en het afhandelen van knooppuntbewerkingen.

AKS biedt een besturingsvlak met één tenant, met een toegewezen API-server, planner, enzovoort. U definieert het aantal en de grootte van de knooppunten en het Azure-platform configureert de beveiligde communicatie tussen het besturingsvlak en de knooppunten. Interactie met het besturingsvlak vindt plaats via Kubernetes-API's, zoals kubectl of het Kubernetes-dashboard.

Hoewel u geen onderdelen (zoals een maximaal beschikbare etcd-winkel ) met dit beheerde besturingsvlak hoeft te configureren, hebt u geen rechtstreeks toegang tot het besturingsvlak. Kubernetes-besturingsvlak- en knooppuntupgrades worden ingedeeld via azure CLI of Azure Portal. Als u mogelijke problemen wilt oplossen, kunt u de logboeken van het besturingsvlak bekijken via Azure Monitor-logboeken.

Als u een besturingsvlak wilt configureren of rechtstreeks wilt openen, implementeert u een zelfbeheerd Kubernetes-cluster met behulp van Cluster API Provider Azure.

Zie Best practices voor clusterbeveiliging en -upgrades in AKS voor de bijbehorende aanbevolen procedures.

Zie de basisbeginselen en prijzen van AKS voor AKS-kosten voor AKS voor informatie over kostenbeheer.

Knooppunten en knooppuntgroepen

Als u uw toepassingen en ondersteunende services wilt uitvoeren, hebt u een Kubernetes-knooppunt nodig. Een AKS-cluster heeft ten minste één knooppunt, een virtuele Azure-machine (VM) waarop de Onderdelen van het Kubernetes-knooppunt en de containerruntime worden uitgevoerd.

Onderdeel	Beschrijving
kubelet	De Kubernetes-agent die de indelingsaanvragen van het besturingsvlak verwerkt, samen met het plannen en uitvoeren van de aangevraagde containers.
kube-proxy	Verwerkt virtuele netwerken op elk knooppunt. De proxy routeert netwerkverkeer en beheert IP-adressering voor services en pods.
containerruntime	Hiermee kunnen in containers geplaatste toepassingen aanvullende resources uitvoeren en ermee werken, zoals het virtuele netwerk of de opslag. AKS-clusters met Kubernetes versie 1.19+ voor Linux-knooppuntgroepen worden gebruikt containerd als containerruntime. Vanaf Kubernetes versie 1.20 voor Windows-knooppuntgroepen containerd kan deze worden gebruikt in preview voor de containerruntime, maar Docker is nog steeds de standaardcontainerruntime. AKS-clusters die gebruikmaken van eerdere versies van Kubernetes voor knooppuntgroepen, gebruiken Docker als containerruntime.

De Azure VM-grootte voor uw knooppunten definieert CPU's, geheugen, grootte en het beschikbare opslagtype (zoals SSD met hoge prestaties of gewone HDD). Plan de grootte van het knooppunt rond of uw toepassingen grote hoeveelheden CPU en geheugen of opslag met hoge prestaties nodig kunnen hebben. Schaal het aantal knooppunten in uw AKS-cluster uit om te voldoen aan de vraag. Zie Schaalopties voor toepassingen in AKS voor meer informatie over schalen.

In AKS is de VM-installatiekopie voor de knooppunten van uw cluster gebaseerd op Ubuntu Linux, Azure Linux of Windows Server 2019. Wanneer u een AKS-cluster maakt of het aantal knooppunten uitschaalt, maakt en configureert het Azure-platform automatisch het aangevraagde aantal virtuele machines. Agentknooppunten worden gefactureerd als standaard-VM's, zodat kortingen op VM-grootte (inclusief Azure-reserveringen) automatisch worden toegepast.

Voor beheerde schijven wordt de standaardschijfgrootte en -prestaties toegewezen op basis van de geselecteerde VM-SKU en het aantal vCPU's. Zie Standaardgrootte van besturingssysteemschijven voor meer informatie.

Als u geavanceerde configuratie en controle nodig hebt voor de containerruntime en het besturingssysteem van uw Kubernetes-knooppunt, kunt u een zelfbeheerd cluster implementeren met behulp van Cluster API Provider Azure.

Resourcereserveringen

AKS maakt gebruik van knooppuntbronnen om de knooppuntfunctie als onderdeel van uw cluster te helpen. Dit gebruik kan een discrepantie creëren tussen de totale resources van uw knooppunt en de toe te voegen resources in AKS. Onthoud deze informatie bij het instellen van aanvragen en limieten voor door de gebruiker geïmplementeerde pods.

Als u de resources van een knooppunt wilt vinden die kunnen worden gebruikt, voert u het volgende uit:

kubectl describe node [NODE_NAME]

Om de prestaties en functionaliteit van knooppunten te behouden, reserveert AKS resources op elk knooppunt. Naarmate een knooppunt groter wordt in resources, neemt de resourcereservering toe vanwege een hogere behoefte aan beheer van door de gebruiker geïmplementeerde pods.

Notitie

Als u AKS-invoegtoepassingen zoals Container Insights (OMS) gebruikt, worden extra knooppuntbronnen gebruikt.

Er zijn twee typen resources gereserveerd:

CPU

Gereserveerde CPU is afhankelijk van het knooppunttype en de clusterconfiguratie, wat kan leiden tot minder toe te schrijven CPU vanwege het uitvoeren van extra functies.

CPU-kernen op host	1	2	4	8	16	32	64
Gereserveerd voor Kube (millicores)	60	100	140	180	260	420	740

Geheugen

Geheugen dat door AKS wordt gebruikt, bevat de som van twee waarden.

Belangrijk

AKS 1.29 previews in januari 2024 en bevat bepaalde wijzigingen in geheugenreserveringen. Deze wijzigingen worden in de volgende sectie beschreven.

AKS 1.29 en hoger

1. kubelet daemon beschikt standaard over de regel memory.available<100Mi eviction. Dit zorgt ervoor dat een knooppunt altijd ten minste 100Mi allocatable heeft. Wanneer een host zich onder die beschikbare geheugendrempel bevindt, wordt de kubelet beëindiging van een van de actieve pods geactiveerd en wordt geheugen vrijgemaakt op de hostcomputer.

2. Een snelheid van geheugenreserveringen die zijn ingesteld op basis van de lagere waarde: 20 MB * Max Pods die worden ondersteund op het knooppunt + 50 MB of 25% van de totale geheugenbronnen van het systeem.

   Voorbeelden:

   • Als de VIRTUELE machine 8 GB geheugen biedt en het knooppunt maximaal 30 pods ondersteunt, reserveert AKS 20 MB * 30 Max Pods + 50 MB = 650 MB voor kube-reserved. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • Als de VM 4 GB geheugen biedt en het knooppunt maximaal 70 pods ondersteunt, reserveert AKS 25% * 4 GB = 1000 MB voor kube-reserved, omdat dit minder dan 20 MB * 70 Max Pods + 50 MB = 1450 MB is.

   Zie Maximumpods per knooppunt configureren in een AKS-cluster voor meer informatie.

AKS-versies vóór 1.29

1. kubelet daemon wordt geïnstalleerd op alle Kubernetes-agentknooppunten om het maken en beëindigen van containers te beheren. Standaard heeft daemon op AKS kubelet de regel memory.available<750Mi eviction, zodat een knooppunt altijd ten minste 750Mi allocatable moet hebben. Wanneer een host lager is dan de beschikbare geheugendrempelwaarde, wordt een kubelet van de actieve pods beëindigd en wordt geheugen vrijgemaakt op de hostcomputer.

2. Een regressieve hoeveelheid geheugenreserveringen voor de kubelet-daemon om goed te functioneren (kube-reserved).

   • 25% van de eerste 4 GB geheugen
   • 20% van de volgende 4 GB geheugen (maximaal 8 GB)
   • 10% van de volgende 8 GB geheugen (maximaal 16 GB)
   • 6% van de volgende 112 GB geheugen (tot 128 GB)
   • 2% van elk geheugen boven 128 GB

Notitie

AKS reserveert een extra 2 GB voor systeemproces in Windows-knooppunten die geen deel uitmaken van het berekende geheugen.

Regels voor geheugen- en CPU-toewijzing zijn ontworpen om het volgende te doen:

• Houd agentknooppunten in orde, inclusief enkele hostingsysteempods die essentieel zijn voor de clusterstatus.
• Ervoor zorgen dat het knooppunt minder toewijsbaar geheugen en CPU rapporteert dan het zou rapporteren als het geen deel uitmaakt van een Kubernetes-cluster.

De bovenstaande resourcereserveringen kunnen niet worden gewijzigd.

Als een knooppunt bijvoorbeeld 7 GB biedt, wordt 34% van het geheugen weergegeven dat niet kan worden toegedeeld, inclusief de drempelwaarde voor harde verwijdering van 750Mi.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

Naast reserveringen voor Kubernetes zelf, behoudt het onderliggende knooppuntbesturingssysteem ook een hoeveelheid CPU- en geheugenbronnen voor het onderhouden van besturingssysteemfuncties.

Zie Best practices voor basisfuncties van scheduler in AKS voor de bijbehorende aanbevolen procedures.

Knooppuntpools

Notitie

De Azure Linux-knooppuntgroep is nu algemeen beschikbaar (GA). Zie de inleiding tot de Azure Linux-containerhost voor AKS voor meer informatie over de voordelen en implementatiestappen.

Knooppunten van dezelfde configuratie worden gegroepeerd in knooppuntgroepen. Een Kubernetes-cluster bevat ten minste één knooppuntgroep. Het eerste aantal knooppunten en de grootte wordt gedefinieerd wanneer u een AKS-cluster maakt, waarmee een standaardknooppuntgroep wordt gemaakt. Deze standaardknooppuntgroep in AKS bevat de onderliggende VM's waarop uw agentknooppunten worden uitgevoerd.

Notitie

Om ervoor te zorgen dat uw cluster betrouwbaar werkt, moet u ten minste twee (2) knooppunten uitvoeren in de standaardknooppuntgroep.

U kunt een AKS-cluster schalen of upgraden naar de standaardknooppuntgroep. U kunt ervoor kiezen om een specifieke knooppuntgroep te schalen of bij te werken. Voor upgradebewerkingen worden actieve containers gepland op andere knooppunten in de knooppuntgroep totdat alle knooppunten zijn bijgewerkt.

Zie Meerdere knooppuntgroepen maken voor een cluster in AKS voor meer informatie over het gebruik van meerdere knooppuntgroepen in AKS.

Knooppuntkiezers

In een AKS-cluster met meerdere knooppuntgroepen moet u mogelijk de Kubernetes Scheduler vertellen welke knooppuntgroep moet worden gebruikt voor een bepaalde resource. Inkomende controllers mogen bijvoorbeeld niet worden uitgevoerd op Windows Server-knooppunten.

Met knooppuntkiezers kunt u verschillende parameters, zoals het knooppuntbesturingssystemen, definiëren om te bepalen waar een pod moet worden gepland.

In het volgende basisvoorbeeld wordt een NGINX-exemplaar op een Linux-knooppunt gepland met behulp van de knooppuntselector 'kubernetes.io/os': linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

Zie Best practices voor geavanceerde scheduler-functies in AKS voor meer informatie over het bepalen waar pods worden gepland.

Knooppuntresourcegroep

Wanneer u een AKS-cluster maakt, moet u een resourcegroep opgeven waarin de clusterresource moet worden gemaakt. Naast deze resourcegroep maakt en beheert de AKS-resourceprovider ook een afzonderlijke resourcegroep met de naam de knooppuntresourcegroep. De knooppuntresourcegroep bevat de volgende infrastructuurresources:

• De virtuele-machineschaalsets en VM's voor elk knooppunt in de knooppuntgroepen
• Het virtuele netwerk voor het cluster
• De opslag voor het cluster

De knooppuntresourcegroep krijgt standaard een naam, zoals MC_myResourceGroup_myAKSCluster_eastus. Tijdens het maken van het cluster kunt u ook de naam opgeven die is toegewezen aan uw knooppuntresourcegroep. Wanneer u uw AKS-cluster verwijdert, verwijdert de AKS-resourceprovider automatisch de knooppuntresourcegroep.

De knooppuntresourcegroep heeft de volgende beperkingen:

• U kunt geen bestaande resourcegroep opgeven voor de knooppuntresourcegroep.
• U kunt geen ander abonnement opgeven voor de knooppuntresourcegroep.
• U kunt de naam van de knooppuntresourcegroep niet wijzigen nadat het cluster is gemaakt.
• U kunt geen namen opgeven voor de beheerde resources in de knooppuntresourcegroep.
• U kunt door Azure gemaakte tags van beheerde resources in de knooppuntresourcegroep niet wijzigen of verwijderen.

Als u door Azure gemaakte tags en andere resource-eigenschappen in de knooppuntresourcegroep wijzigt of verwijdert, krijgt u onverwachte resultaten, zoals het schalen en upgraden van fouten. Als AKS de levenscyclus van infrastructuur in de knooppuntresourcegroep beheert, worden alle wijzigingen in uw cluster verplaatst naar een niet-ondersteunde status.

Een veelvoorkomend scenario waarin klanten resources willen wijzigen, is via tags. Met AKS kunt u tags maken en wijzigen die worden doorgegeven aan resources in de knooppuntresourcegroep en u kunt deze tags toevoegen wanneer u het cluster maakt of bijwerkt . U kunt aangepaste tags maken of wijzigen, bijvoorbeeld om een bedrijfseenheid of kostenplaats toe te wijzen. Dit kan ook worden bereikt door Azure-beleid te maken met een bereik voor de beheerde resourcegroep.

Het wijzigen van door Azure gemaakte tags op resources onder de knooppuntresourcegroep in het AKS-cluster is een niet-ondersteunde actie die de serviceniveaudoelstelling (SLO) onderbreekt. Zie Voor meer informatie, biedt AKS een service level agreement?

Als u de kans wilt verkleinen dat wijzigingen in de knooppuntresourcegroep van invloed zijn op uw clusters, kunt u vergrendeling van knooppuntresourcegroepen inschakelen om een weigeringstoewijzing toe te passen op uw AKS-resources. Meer informatie vindt u in clusterconfiguratie in AKS.

Waarschuwing

Als u geen vergrendeling van de knooppuntresourcegroep hebt ingeschakeld, kunt u elke resource in de knooppuntresourcegroep rechtstreeks wijzigen. Het rechtstreeks wijzigen van resources in de knooppuntresourcegroep kan ertoe leiden dat uw cluster instabiel of niet meer reageert.

Pods

Kubernetes maakt gebruik van pods om een exemplaar van uw toepassing uit te voeren. Een pod vertegenwoordigt één exemplaar van uw toepassing.

Pods hebben doorgaans een 1:1-toewijzing met een container. In geavanceerde scenario's kan een pod meerdere containers bevatten. Pods met meerdere containers worden samen gepland op hetzelfde knooppunt en stellen containers in staat gerelateerde resources te delen.

Wanneer u een pod maakt, kunt u resourceaanvragen definiëren om een bepaalde hoeveelheid CPU- of geheugenresources aan te vragen. De Kubernetes Scheduler probeert te voldoen aan de aanvraag door de pods te plannen om te worden uitgevoerd op een knooppunt met beschikbare resources. U kunt ook maximale resourcelimieten opgeven om te voorkomen dat een pod te veel rekenresource van het onderliggende knooppunt verbruikt. Best practice is het opnemen van resourcelimieten voor alle pods om de Kubernetes Scheduler te helpen de benodigde, toegestane resources te identificeren.

Zie Kubernetes-pods en kubernetes-podlevenscyclus voor meer informatie.

Een pod is een logische resource, maar toepassingsworkloads worden uitgevoerd op de containers. Pods zijn meestal kortstondige, wegwerpresources. Afzonderlijke geplande pods missen enkele functies voor hoge beschikbaarheid en redundantie van Kubernetes. In plaats daarvan worden pods geïmplementeerd en beheerd door Kubernetes-controllers, zoals de implementatiecontroller.

Implementaties en YAML-manifesten

Een implementatie vertegenwoordigt identieke pods die worden beheerd door de Kubernetes Deployment Controller. Een implementatie definieert het aantal podreplica's dat moet worden gemaakt. De Kubernetes Scheduler zorgt ervoor dat extra pods worden gepland op gezonde knooppunten als pods of knooppunten problemen ondervinden.

U kunt implementaties bijwerken om de configuratie van pods, gebruikte containerinstallatiekopieën of gekoppelde opslag te wijzigen. De implementatiecontroller:

• Leegloopt en beëindigt een bepaald aantal replica's.
• Hiermee maakt u replica's op basis van de nieuwe implementatiedefinitie.
• Hiermee wordt het proces voortgezet totdat alle replica's in de implementatie zijn bijgewerkt.

De meeste stateless toepassingen in AKS moeten het implementatiemodel gebruiken in plaats van afzonderlijke pods te plannen. Kubernetes kan de implementatiestatus en -status bewaken om ervoor te zorgen dat het vereiste aantal replica's wordt uitgevoerd in het cluster. Wanneer pods afzonderlijk worden gepland, worden ze niet opnieuw opgestart als ze een probleem ondervinden en niet opnieuw worden gepland op knooppunten met een goede status als hun huidige knooppunt een probleem ondervindt.

U wilt geen beheerbeslissingen verstoren met een updateproces als uw toepassing een minimum aantal beschikbare exemplaren vereist. Budgetten voor podonderbreking definiëren hoeveel replica's in een implementatie kunnen worden uitgepakt tijdens een update of knooppuntupgrade. Als u bijvoorbeeld vijf (5) replica's in uw implementatie hebt, kunt u een podonderbreking van 4 (vier) definiëren om slechts één replica tegelijk te verwijderen of opnieuw te plannen. Net als bij resourcelimieten voor pods kunt u het beste budgetten voor podonderbreking definiëren voor toepassingen waarvoor een minimum aantal replica's moet worden gebruikt om altijd aanwezig te zijn.

Implementaties worden doorgaans gemaakt en beheerd met kubectl create of kubectl apply. Maak een implementatie door een manifestbestand in de YAML-indeling te definiëren.

In het volgende voorbeeld wordt een basisimplementatie van de NGINX-webserver gemaakt. De implementatie geeft drie (3) replica's op die moeten worden gemaakt en vereist dat poort 80 is geopend op de container. Resourceaanvragen en -limieten worden ook gedefinieerd voor CPU en geheugen.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

Een uitsplitsing van de implementatiespecificaties in het YAML-manifestbestand is als volgt:

Specificatie	Beschrijving
.apiVersion	Hiermee geeft u de API-groep en API-resource die u wilt gebruiken bij het maken van de resource.
.kind	Hiermee geeft u het type resource dat u wilt maken.
.metadata.name	Hiermee geeft u de naam van de implementatie. Met dit bestand wordt de nginx-installatiekopieën uitgevoerd vanuit Docker Hub.
.spec.replicas	Hiermee geeft u op hoeveel pods moeten worden gemaakt. Met dit bestand worden drie dubbele pods gemaakt.
.spec.selector	Hiermee geeft u op welke pods worden beïnvloed door deze implementatie.
.spec.selector.matchLabels	Bevat een kaart van {key, waarde} -paren waarmee de implementatie de gemaakte pods kan vinden en beheren.
.spec.selector.matchLabels.app	Moet overeenkomen .spec.template.metadata.labels.
.spec.template.labels	Hiermee geeft u de paren {key, value} die aan het object zijn gekoppeld.
.spec.template.app	Moet overeenkomen .spec.selector.matchLabels.
.spec.spec.containers	Hiermee geeft u de lijst met containers die deel uitmaken van de pod.
.spec.spec.containers.name	Hiermee geeft u de naam van de container die is opgegeven als een DNS-label.
.spec.spec.containers.image	Hiermee geeft u de naam van de containerinstallatiekopieën.
.spec.spec.containers.ports	Hiermee geeft u de lijst met poorten die moeten worden weergegeven vanuit de container.
.spec.spec.containers.ports.containerPort	Hiermee geeft u het aantal poorten op dat moet worden weergegeven op het IP-adres van de pod.
.spec.spec.resources	Hiermee geeft u de rekenresources op die vereist zijn voor de container.
.spec.spec.resources.requests	Hiermee geeft u de minimale hoeveelheid rekenresources op die vereist is.
.spec.spec.resources.requests.cpu	Hiermee geeft u de minimale hoeveelheid CPU vereist.
.spec.spec.resources.requests.memory	Hiermee geeft u de minimale hoeveelheid geheugen vereist.
.spec.spec.resources.limits	Hiermee geeft u de maximale hoeveelheid rekenresources op die is toegestaan. Deze limiet wordt afgedwongen door de kubelet.
.spec.spec.resources.limits.cpu	Hiermee geeft u de maximale hoeveelheid CPU op die is toegestaan. Deze limiet wordt afgedwongen door de kubelet.
.spec.spec.resources.limits.memory	Hiermee geeft u de maximale hoeveelheid geheugen op die is toegestaan. Deze limiet wordt afgedwongen door de kubelet.

Complexere toepassingen kunnen worden gemaakt door services (zoals load balancers) toe te passen in het YAML-manifest.

Zie Kubernetes-implementaties voor meer informatie.

Pakketbeheer met Helm

Helm wordt vaak gebruikt voor het beheren van toepassingen in Kubernetes. U kunt resources implementeren door bestaande openbare Helm-grafieken te bouwen en te gebruiken die een verpakte versie van toepassingscode en Kubernetes YAML-manifesten bevatten. U kunt Helm-grafieken lokaal of in een externe opslagplaats opslaan, zoals een Azure Container Registry Helm-grafiekopslagplaats.

Als u Helm wilt gebruiken, installeert u de Helm-client op uw computer of gebruikt u de Helm-client in Azure Cloud Shell. Zoek of maak Helm-grafieken en installeer deze vervolgens in uw Kubernetes-cluster. Zie Bestaande toepassingen installeren met Helm in AKS voor meer informatie.

StatefulSets en DaemonSets

Met behulp van de Kubernetes Scheduler voert de implementatiecontroller replica's uit op elk beschikbaar knooppunt met beschikbare resources. Hoewel deze aanpak mogelijk voldoende is voor staatloze toepassingen, is de implementatiecontroller niet ideaal voor toepassingen die het volgende vereisen:

• Een permanente naamconventie of opslag.
• Er bestaat een replica op elk select-knooppunt in een cluster.

Met twee Kubernetes-resources kunt u echter deze typen toepassingen beheren:

• StatefulSets behouden de status van toepassingen na de levenscyclus van een afzonderlijke pod.
• DaemonSets zorgen voor een actief exemplaar op elk knooppunt, vroeg in het Kubernetes bootstrap-proces.

StatefulSets

Moderne toepassingsontwikkeling is vaak gericht op staatloze toepassingen. Voor stateful toepassingen, zoals toepassingen die databaseonderdelen bevatten, kunt u StatefulSets gebruiken. Net als bij implementaties maakt en beheert een StatefulSet ten minste één identieke pod. Replica's in een StatefulSet volgen een graceful, sequentiële benadering voor implementatie, schaal, upgrade en beëindiging. De naamconventie, netwerknamen en opslag blijven behouden als replica's opnieuw worden gepland met een StatefulSet.

Definieer de toepassing in YAML-indeling met behulp van kind: StatefulSet. Van daaruit verwerkt de StatefulSet-controller de implementatie en het beheer van de vereiste replica's. Gegevens worden geschreven naar permanente opslag, geleverd door Azure Managed Disks of Azure Files. Met StatefulSets blijft de onderliggende permanente opslag behouden, zelfs wanneer de StatefulSet wordt verwijderd.

Zie Kubernetes StatefulSets voor meer informatie.

Replica's in een StatefulSet worden gepland en uitgevoerd op elk beschikbaar knooppunt in een AKS-cluster. Als u ervoor wilt zorgen dat ten minste één pod in uw set wordt uitgevoerd op een knooppunt, gebruikt u in plaats daarvan een DaemonSet.

DaemonSets

Voor specifieke logboekverzameling of bewaking moet u mogelijk een pod uitvoeren op alle knooppunten of een selecte set knooppunten. U kunt DaemonSets gebruiken om te implementeren op een of meer identieke pods. De DaemonSet-controller zorgt ervoor dat elk knooppunt dat is opgegeven een exemplaar van de pod uitvoert.

De DaemonSet-controller kan pods vroeg in het opstartproces van het cluster plannen voordat de standaard Kubernetes-planner is gestart. Deze mogelijkheid zorgt ervoor dat de pods in een DaemonSet worden gestart voordat traditionele pods in een Implementatie of StatefulSet worden gepland.

Net als StatefulSets wordt een DaemonSet gedefinieerd als onderdeel van een YAML-definitie met behulp van kind: DaemonSet.

Zie Kubernetes DaemonSets voor meer informatie.

Notitie

Als u de invoegtoepassing Virtuele knooppunten gebruikt, maakt DaemonSets geen pods op het virtuele knooppunt.

Naamruimten

Kubernetes-resources, zoals pods en implementaties, worden logisch gegroepeerd in een naamruimte om een AKS-cluster te verdelen en de toegang tot resources te maken, weer te geven of te beheren. U kunt bijvoorbeeld naamruimten maken om bedrijfsgroepen van elkaar te scheiden. Gebruikers kunnen alleen communiceren met resources binnen de aan hen toegewezen naamruimten.

Wanneer u een AKS-cluster maakt, zijn de volgende naamruimten beschikbaar:

Naamruimte	Beschrijving
default	Waar pods en implementaties standaard worden gemaakt wanneer er geen wordt opgegeven. In kleinere omgevingen kunt u toepassingen rechtstreeks implementeren in de standaardnaamruimte zonder dat u extra logische scheidingen hoeft te maken. Wanneer u communiceert met de Kubernetes-API, zoals met kubectl get pods, wordt de standaardnaamruimte gebruikt wanneer er geen is opgegeven.
kube-system	Waar kernresources bestaan, zoals netwerkfuncties zoals DNS en proxy, of het Kubernetes-dashboard. Doorgaans implementeert u uw eigen toepassingen niet in deze naamruimte.
kube-public	Normaal gesproken niet gebruikt, maar kan worden gebruikt voor resources die zichtbaar zijn in het hele cluster en kunnen worden weergegeven door elke gebruiker.

Zie Kubernetes-naamruimten voor meer informatie.

Volgende stappen

In dit artikel worden enkele van de belangrijkste Kubernetes-onderdelen behandeld en hoe ze van toepassing zijn op AKS-clusters. Zie de volgende artikelen voor meer informatie over de belangrijkste Kubernetes- en AKS-concepten:

• AKS-toegang en -identiteit
• AKS-beveiliging
• Virtuele AKS-netwerken
• AKS-opslag
• AKS-schaal