Basisconcepten van Kubernetes voor Azure Kubernetes Service (AKS)

In dit artikel worden de kernconcepten van Azure Kubernetes Service (AKS) beschreven, een beheerde Kubernetes-service die u kunt gebruiken om containertoepassingen op schaal te implementeren en te gebruiken in Azure. Het helpt u meer te weten te komen over de infrastructuuronderdelen van Kubernetes en een beter inzicht te krijgen in de werking van Kubernetes in AKS.

Wat is Kubernetes?

Kubernetes is een snel evoluerend platform dat containertoepassingen en de bijbehorende netwerk- en opslagonderdelen beheert. Kubernetes richt zich op de toepassingsworkloads en 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 staatloze en stateful 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. 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:

• Het besturingsvlak, dat de belangrijkste Kubernetes-services en indeling van toepassingsworkloads biedt, en
• Knooppunten, waarop uw toepassingsworkloads worden uitgevoerd.

Besturingsvlak

Wanneer u een AKS-cluster maakt, maakt en configureert het Azure-platform automatisch het bijbehorende besturingsvlak. Dit besturingsvlak met één tenant 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 waar u het cluster hebt gemaakt.

Het besturingsvlak bevat de volgende kubernetes-kernonderdelen:

Onderdeel	Beschrijving
kube-apiserver	De API-server maakt de onderliggende Kubernetes-API's beschikbaar en biedt de interactie voor beheerhulpprogramma's, zoals kubectl of het Kubernetes-dashboard.
etcd	etcd is een maximaal beschikbare sleutel-waardearchief in Kubernetes waarmee de status van uw Kubernetes-cluster en -configuratie behouden blijft.
kube-scheduler	Wanneer u toepassingen maakt of schaalt, bepaalt de scheduler welke knooppunten de workload kunnen uitvoeren en worden de geïdentificeerde knooppunten gestart.
kube-controller-manager	De controllerbeheerder houdt toezicht op een aantal kleinere controllers die acties uitvoeren, zoals het repliceren van pods en het verwerken van knooppuntbewerkingen.

Houd er rekening mee dat u niet rechtstreeks toegang hebt 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 met behulp van Azure Monitor.

Knooppunten

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

Knooppunten bevatten de volgende kubernetes-kernonderdelen:

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	De proxy verwerkt virtuele netwerken op elk knooppunt, routering van netwerkverkeer en het beheren van IP-adressering voor services en pods.
containerruntime	Met de containerruntime kunnen toepassingen in containers worden uitgevoerd en communiceren met andere resources, zoals het virtuele netwerk of de opslag. Zie Container Runtime-configuratie voor meer informatie.

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 2022. 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 worden de standaardschijfgrootte en -prestaties toegewezen aan de geselecteerde VM-SKU en het aantal vCPU's. Zie Standaardgrootte van besturingssysteemschijven voor meer informatie.

Configuratie van besturingssysteem

AKS ondersteunt Ubuntu 22.04 en Azure Linux 2.0 als het knooppuntbesturingssysteem (OS) voor clusters met Kubernetes 1.25 en hoger. Ubuntu 18.04 kan ook worden opgegeven bij het maken van een knooppuntgroep voor Kubernetes-versies 1.24 en lager.

AKS ondersteunt Windows Server 2022 als het standaardbesturingssysteem voor Windows-knooppuntgroepen in clusters met Kubernetes 1.25 en hoger. Windows Server 2019 kan ook worden opgegeven bij het maken van een knooppuntgroep voor Kubernetes-versies 1.32 en lager. Windows Server 2019 wordt buiten gebruik gesteld nadat Kubernetes versie 1.32 het einde van de levensduur bereikt en niet wordt ondersteund in toekomstige releases. Zie de opmerkingen bij de release van AKS voor meer informatie over deze buitengebruikstelling.

Configuratie van containerruntime

Een containerruntime is software waarmee containers worden uitgevoerd en containerinstallatiekopieën op een knooppunt worden beheerd. De runtime helpt sys-aanroepen of besturingssysteemspecifieke functionaliteit weg te werken om containers uit te voeren op Linux of Windows. Voor Linux-knooppuntgroepen containerd wordt gebruikgemaakt van Kubernetes versie 1.19 en hoger. Voor Windows Server 2019- en 2022-knooppuntgroepen containerd is het algemeen beschikbaar en is dit de enige runtimeoptie op Kubernetes versie 1.23 en hoger. Vanaf mei 2023 wordt Docker buiten gebruik gesteld en wordt deze niet meer ondersteund. Zie de opmerkingen bij de release van AKS voor meer informatie over deze buitengebruikstelling.

Containerd is een compatibele kerncontainerruntime van OCI (Open Container Initiative) die de minimale set vereiste functionaliteit biedt voor het uitvoeren van containers en het beheren van installatiekopieën op een knooppunt. Metcontainerd op knooppunten en knooppuntgroepen praat de kubelet rechtstreeks met containerd behulp van de CRI-invoegtoepassing (Container Runtime Interface), waarbij extra hops in de gegevensstroom worden verwijderd in vergelijking met de Docker CRI-implementatie. Daarom ziet u een betere opstartlatentie voor pods en minder resourcegebruik (CPU en geheugen).

Containerd werkt op elke GA-versie van Kubernetes in AKS, in elke Kubernetes-versie vanaf v1.19 en ondersteunt alle Kubernetes- en AKS-functies.

containerd beperkingen/verschillen

• Voor containerd, raden we u aan te gebruiken crictl als vervanging voor de Docker CLI voor het oplossen van problemen met pods, containers en containerinstallatiekopieën op Kubernetes-knooppunten. Zie algemene opties voor gebruik en clientconfiguratie voor meer informatiecrictl.

  • Containerd biedt niet de volledige functionaliteit van de Docker CLI. Deze is alleen beschikbaar voor probleemoplossing.
  • crictl biedt een meer Kubernetes-beschrijvende weergave van containers, met concepten zoals pods, enzovoort.

• Containerd stelt logboekregistratie in met behulp van de gestandaardiseerde cri indeling voor logboekregistratie. Uw logboekregistratieoplossing moet ondersteuning bieden voor de cri indeling voor logboekregistratie, zoals Azure Monitor voor containers.

• U hebt geen toegang meer tot de Docker-engine /var/run/docker.sockof kunt Docker-in-Docker (DinD) gebruiken.

  • Als u momenteel toepassingslogboeken of bewakingsgegevens uit docker-engine extraheert, gebruikt u In plaats daarvan Container Insights . AKS biedt geen ondersteuning voor het uitvoeren van out-of-band-opdrachten op de agentknooppunten die instabiliteit kunnen veroorzaken.
  • Het is niet raadzaam installatiekopieën te bouwen of rechtstreeks met behulp van de Docker-engine. Kubernetes is niet volledig op de hoogte van deze verbruikte resources en deze methoden bieden talloze problemen, zoals hier en hier wordt beschreven.

• Wanneer u installatiekopieën bouwt, kunt u uw huidige Docker-buildwerkstroom gewoon blijven gebruiken, tenzij u installatiekopieën in uw AKS-cluster bouwt. In dit geval kunt u overschakelen naar de aanbevolen methode voor het bouwen van installatiekopieën met behulp van ACR Tasks of een veiligere optie in het cluster, zoals Docker Buildx.

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 allocatable resource van een knooppunt wilt vinden, kunt u de kubectl describe node opdracht gebruiken:

kubectl describe node [NODE_NAME]

Om de prestaties en functionaliteit van knooppunten te behouden, reserveert AKS twee typen resources, CPU en geheugen 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. Houd er rekening mee dat de resourcereserveringen niet kunnen worden gewijzigd.

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. In de volgende tabel ziet u de CPU-reservering in millicores:

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

Geheugen

Gereserveerd geheugen in AKS bevat de som van twee waarden:

AKS 1.29 en hoger

1. kubelet daemon beschikt standaard over de regel memory.available<100Mi eviction. Deze regel zorgt ervoor dat een knooppunt te allen tijde 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 heeft standaard de regel memory.available<750Mi eviction. Deze regel zorgt ervoor dat een knooppunt altijd ten minste 750Mi 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 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 meer dan 128 GB

Regels voor geheugen- en CPU-toewijzing zijn ontworpen voor:

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

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

Knooppunten van dezelfde configuratie worden gegroepeerd in knooppuntgroepen. Elk Kubernetes-cluster bevat ten minste één knooppuntgroep. U definieert het eerste aantal knooppunten en grootten 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.

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 Knooppuntgroepen maken en knooppuntgroepen beheren voor meer informatie.

Standaardgrootte van besturingssysteemschijf

Wanneer u een nieuw cluster maakt of een nieuwe knooppuntgroep toevoegt aan een bestaand cluster, bepaalt het aantal vCPU's standaard de grootte van de besturingssysteemschijf. Het aantal vCPU's is gebaseerd op de VM-SKU. De volgende tabel bevat de standaardschijfgrootte van het besturingssysteem voor elke VM-SKU:

VM SKU Cores (vCPU's)	Standaardlaag van besturingssysteemschijf	Ingerichte IOPS	Ingerichte doorvoer (Mbps)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

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. U gebruikt knooppuntkiezers om verschillende parameters, zoals het knooppuntbesturingssystemen, te 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.

Knooppuntresourcegroep

Wanneer u een AKS-cluster maakt, geeft u een Azure-resourcegroep op waarin u de clusterresources wilt maken. Naast deze resourcegroep maakt en beheert de AKS-resourceprovider 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 met de volgende indeling: MC_resourceGroupName_clusterName_location. Tijdens het maken van het cluster kunt u de naam opgeven die is toegewezen aan uw knooppuntresourcegroep. Wanneer u een Azure Resource Manager-sjabloon gebruikt, kunt u de naam definiëren met behulp van de nodeResourceGroup eigenschap. Wanneer u Azure CLI gebruikt, gebruikt u de --node-resource-group parameter met de az aks create opdracht, zoals wordt weergegeven in het volgende voorbeeld:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

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.

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. Als u door Azure gemaakte tags of andere resource-eigenschappen in de knooppuntresourcegroep wijzigt of verwijdert, krijgt u mogelijk onverwachte resultaten, zoals het schalen en upgraden van fouten. AKS beheert de levenscyclus van de infrastructuur in de knooppuntresourcegroep, dus als u wijzigingen aanbrengt, wordt uw cluster verplaatst naar een niet-ondersteunde status. Zie Voor meer informatie, biedt AKS een service level agreement?

Met AKS kunt u tags maken en wijzigen die worden doorgegeven aan resources in de knooppuntresourcegroep. U kunt deze tags toevoegen wanneer u het cluster maakt of bijwerkt . U kunt aangepaste tags maken of wijzigen om bijvoorbeeld een bedrijfseenheid of kostenplaats toe te wijzen. U kunt ook Azure-beleid maken met een bereik voor de beheerde resourcegroep.

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. Zie Volledig beheerde resourcegroep (preview) voor meer informatie.

Pods

Kubernetes maakt gebruik van pods om exemplaren van uw toepassing uit te voeren. Eén 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 voor een bepaalde hoeveelheid CPU of geheugen definiëren. 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. De aanbevolen aanbevolen procedure is om resourcelimieten op te nemen 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 Kubernetes-controllers, zoals de implementatiecontroller, pods geïmplementeerd en beheerd.

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, de containerinstallatiekopieën of de gekoppelde opslag te wijzigen.

De implementatiecontroller beheert de levenscyclus van de implementatie en voert de volgende acties uit:

• 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 worden ze niet opnieuw gepland op gezonde knooppunten 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 replica's in uw implementatie hebt, kunt u een podonderbreking van vier definiëren, zodat slechts één replica tegelijk kan worden verwijderd of opnieuw kan worden gepland. Net als bij resourcelimieten voor pods is het raadzaam om budgetten voor podonderbreking te definiëren voor toepassingen waarvoor een minimum aantal replica's altijd aanwezig moet zijn.

Implementaties worden doorgaans gemaakt en beheerd met kubectl create of kubectl apply. U kunt een implementatie maken door een manifestbestand in de YAML-indeling te definiëren. In het volgende voorbeeld ziet u een manifestbestand voor de basisimplementatie voor een NGINX-webserver:

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. In dit voorbeeld van het YAML-bestand wordt de nginx-installatiekopieën uitgevoerd vanuit Docker Hub.
.spec.replicas	Hiermee geeft u op hoeveel pods moeten worden gemaakt. In dit voorbeeld maakt het YAML-bestand drie dubbele pods.
.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. De kubelet dwingt deze limiet af.
.spec.spec.resources.limits.cpu	Hiermee geeft u de maximale hoeveelheid CPU op die is toegestaan. De kubelet dwingt deze limiet af.
.spec.spec.resources.limits.memory	Hiermee geeft u de maximale hoeveelheid geheugen op die is toegestaan. De kubelet dwingt deze limiet af.

Complexere toepassingen kunnen worden gemaakt door onder andere services, zoals load balancers, in het YAML-manifest te gebruiken.

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

De implementatiecontroller maakt gebruik van de Kubernetes Scheduler en voert replica's uit op elk beschikbaar knooppunt met beschikbare resources. Hoewel deze benadering mogelijk voldoende is voor staatloze toepassingen, is de implementatiecontroller niet ideaal voor toepassingen waarvoor de volgende specificaties zijn vereist:

• 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 en DaemonSets.

StatefulSets behouden de status van toepassingen na de levenscyclus van een afzonderlijke pod. DaemonSets zorgen ervoor dat een actief exemplaar op elk knooppunt vroeg in het Kubernetes bootstrap-proces wordt uitgevoerd.

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ëindigingsbewerkingen. De naamconventie, netwerknamen en opslag blijven behouden als replica's opnieuw worden gepland met een StatefulSet.

U kunt de toepassing definiëren 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.

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 wordt gestart. Deze mogelijkheid zorgt ervoor dat de pods in een DaemonSet-status worden gepland voordat traditionele pods in een Implementatie of StatefulSet worden gepland.

Net als StatefulSets kunt u een DaemonSet definiëren als onderdeel van een YAML-definitie met behulp van kind: DaemonSet.

Zie Kubernetes DaemonSets voor meer informatie.

Naamruimten

Kubernetes-resources, zoals pods en implementaties, worden logisch gegroepeerd in naamruimten 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.

De volgende naamruimten zijn beschikbaar wanneer u een AKS-cluster maakt:

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, kunt u deze gebruiken voor resources die zichtbaar zijn in het hele cluster en kunnen worden weergegeven door elke gebruiker.

Zie Kubernetes-naamruimten voor meer informatie.

Volgende stappen

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