Kubernetes-kernconcepten voor Azure Kubernetes Service (AKS)

De ontwikkeling van toepassingen gaat steeds verder naar een op containers gebaseerde benadering, waardoor de noodzaak om resources te beheren en te beheren toeneemt. Kubernetes is het toonaangevende platform en biedt 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 wordt het volgende beschreven:

• Kernonderdelen van kubernetes-infrastructuur:
  • besturingsvlak
  • Knooppunten
  • knooppuntgroepen
• Workloadbronnen:
  • Peulen
  • Implementaties
  • Ingesteld
• Resources groepeert in naamruimten.

Wat is Kubernetes?

Kubernetes is een snel ontwikkelend platform dat containertoepassingen en de bijbehorende netwerk- en opslagonderdelen beheert. Kubernetes richt zich op de workloads van de toepassing, niet op de onderliggende infrastructuuronderdelen. Kubernetes biedt een declaratieve benadering van implementaties, met ondersteuning van 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 in te delen en te beheren. Kubernetes ondersteunt staatloze en stateful toepassingen naarmate teams de implementatie van op microservices gebaseerde toepassingen doormaakt.

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, zoals upgradecoördinatie, vermindert. Het Azure-platform beheert het AKS-besturingsvlak en u betaalt alleen voor de AKS-knooppunten waarop uw toepassingen worden uitgevoerd. AKS is gebaseerd op de open-source Azure Kubernetes Service Engine: aks-engine.

Kubernetes-clusterarchitectuur

Een Kubernetes-cluster is onderverdeeld in twee onderdelen:

• Besturingsvlak: biedt de belangrijkste Kubernetes-services en de orchestration van toepassingsworkloads.
• Knooppunten: voer de workloads van uw toepassing 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 wordt geabstraheerd door de gebruiker. U betaalt alleen voor de knooppunten die zijn gekoppeld aan het AKS-cluster. Het besturingsvlak en de resources bevinden zich alleen in de regio waar u het cluster hebt gemaakt.

Het besturingsvlak bevat de volgende Kubernetes-kernonderdelen:

AKS biedt een besturingsvlak met één tenant, met een toegewezen API-server, scheduler, 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, kubectl zoals of het Kubernetes-dashboard.

Hoewel u geen onderdelen (zoals een opslag met hoge beschikbare enzovoort) hoeft te configureren met dit beheerde besturingsvlak, hebt u niet rechtstreeks toegang tot het besturingsvlak. Kubernetes-besturingsvlak- en knooppuntupgrades worden uitgevoerd via de 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 uw eigen Kubernetes-cluster met behulp van aks-engine.

Zie Best practices for cluster security and upgrades in AKS (Best practices voor clusterbeveiliging en -upgrades in AKS) voor de bijbehorende best practices.

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) die de Kubernetes-knooppuntonderdelen en containerruntime uitvoeren.

De Azure VM-grootte voor uw knooppunten definieert de opslag-CPU's, het geheugen, de grootte en het type die beschikbaar zijn (zoals high-performance SSD of gewone HDD). Plan de knooppuntgrootte om te bepalen of voor uw toepassingen grote hoeveelheden CPU en geheugen of opslag met hoge prestaties nodig zijn. Schaal het aantal knooppunten in uw AKS-cluster uit om aan de vraag te voldoen.

In AKS is de VM-afbeelding voor de knooppunten van uw cluster gebaseerd op Ubuntu 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 VM's. Agentknooppunten worden gefactureerd als standaard-VM's, dus eventuele kortingen voor VM-grootten (inclusief Azure-reserveringen)worden automatisch toegepast.

Implementeer uw eigen Kubernetes-cluster met aks-engine als u een ander hostbesturingssysteem, containerruntime of verschillende aangepaste pakketten gebruikt. De upstream aks-engine brengt functies uit en biedt configuratieopties voorafgaand aan ondersteuning in AKS-clusters. Dus als u een andere containerruntime dan of Docker wilt gebruiken, kunt u uitvoeren om een containerd Kubernetes-cluster te configureren en te implementeren dat voldoet aks-engine aan uw huidige behoeften.

Resourcereserveringen

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

Voer het volgende uit om de toewijsbare resources van een knooppunt te vinden:

kubectl describe node [NODE_NAME]

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

Er zijn twee soorten resources gereserveerd:

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

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

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

  1. kubelet Daemon
     De kubelet daemon wordt geïnstalleerd op alle Knooppunten van de Kubernetes-agent om het maken en beëindigen van containers te beheren.

     In AKS beschikt de daemon standaard over de kubelet memory.available<750Mi-regel voor het uitwijsen van gegevens, zodat een knooppunt altijd ten minste 750 Mi kan worden toewijst. Wanneer een host onder de drempelwaarde voor beschikbaar geheugen komt, wordt de trigger gebruikt om een van de pods die worden uitgevoerd te beëindigen en geheugen vrij te maken kubelet op de hostmachine.

  2. Een regressieve snelheid van 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 (maximaal 128 GB)
     • 2% van elk geheugen dat hoger is dan 128 GB

Toewijzingsregels voor geheugen en CPU:

• Houd agentknooppunten in orde, inclusief enkele hostingsysteempods die essentieel zijn voor de clustertoestand.
• Ervoor zorgen dat het knooppunt minder toewijsbaar geheugen en CPU rapporteert dan wanneer 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 niet toewijsbaar, inclusief de drempelwaarde van 750Mi voor harde uitzetting.

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

Naast reserveringen voor Kubernetes zelf reserveert het onderliggende knooppuntbesturingssysteem ook een hoeveelheid CPU- en geheugenbronnen om functies van het besturingssysteem te onderhouden.

Zie Best practices for basic scheduler features in AKS (Best practices voor basisfuncties van scheduler in AKS) voor de bijbehorende best practices.

Knooppuntpools

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

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

Zie Create and manage multiple node pools for a cluster in AKS(Meerdere knooppuntgroepen maken en beheren voor een cluster in AKS) voor meer informatie over het gebruik van meerdere knooppuntgroepen in AKS.

Knooppunt-selectors

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

Met knooppunt selectors kunt u verschillende parameters definiëren, zoals knooppuntbesturingssysteem, om te bepalen waar een pod moet worden gepland.

In het volgende eenvoudige voorbeeld wordt een NGINX-exemplaar op een Linux-knooppunt gepland met behulp van de knooppunt selector "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 for advanced scheduler features in AKS (Best practices voor geavanceerde scheduler-functies in AKS)voor meer informatie over het bepalen waar pods worden gepland.

Peulen

Kubernetes gebruikt 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 op hetzelfde knooppunt gepland en bieden containers de mogelijkheid om 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 aan de aanvraag te voldoen door te plannen dat de pods worden uitgevoerd op een knooppunt met beschikbare resources. U kunt ook maximale resourcelimieten opgeven om te voorkomen dat een pod te veel rekenresources van het onderliggende knooppunt verbruikt. De best practice is om resourcelimieten voor alle pods op te nemen, om de Kubernetes Scheduler te helpen de benodigde, toegestane resources te identificeren.

Zie Kubernetes pods and Kubernetes pod lifecycle (Levenscyclus van Kubernetes-pods) voor meer informatie.

Een pod is een logische resource, maar toepassingsworkloads worden uitgevoerd op de containers. Pods zijn doorgaans kortstondige, beschikbare resources. Afzonderlijke geplande pods missen enkele van de Kubernetes-functies voor hoge beschikbaarheid en redundantie. 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-implementatiecontroller. Een implementatie definieert het aantal podreplica's dat moet worden gemaakt. De Kubernetes Scheduler zorgt ervoor dat extra pods worden gepland op knooppunten die in orde zijn als pods of knooppunten problemen ondervinden.

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

• Een bepaald aantal replica's wordt leeg gemaakt en beëindigd.
• Hiermee maakt u replica's van de nieuwe implementatiedefinitie.
• Het proces wordt voortgezet totdat alle replica's in de implementatie zijn bijgewerkt.

De meeste staatloze toepassingen in AKS moeten gebruikmaken van het implementatiemodel in plaats van afzonderlijke pods te plannen. Kubernetes kan de status en status van de implementatie bewaken om ervoor te zorgen dat het vereiste aantal replica's binnen het cluster wordt uitgevoerd. Wanneer pods afzonderlijk worden gepland, worden ze niet opnieuw gestart als er een probleem is en worden ze niet opnieuw gepland op knooppunten die in orde zijn als hun huidige knooppunt een probleem ondervindt.

U wilt de beheerbeslissingen niet verstoren met een updateproces als uw toepassing een minimum aantal beschikbare exemplaren vereist. Budgetten voor podonderbreking definiëren hoeveel replica's in een implementatie tijdens een update of knooppuntupgrade kunnen worden uitgenomen. Als u bijvoorbeeld vijf (5) replica's in uw implementatie hebt, kunt u een podonderbreking van 4 (vier) definiëren zodat er slechts één replica tegelijk kan worden verwijderd of opnieuw hoeft te worden gepland. Net als bij podresourcelimieten is best practice het definiëren van podonderbrekingsbudgetten voor toepassingen waarvoor een minimum aantal replica's altijd aanwezig moet zijn.

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

In het volgende voorbeeld wordt een basisimplementatie van de NGINX-webserver gemaakt. De implementatie specificeert drie (3) replica's 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

Complexere toepassingen kunnen worden gemaakt door services (zoals load balancers) op te neemt 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 de 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 benadering voldoende kan zijn voor staatloze toepassingen, is de implementatiecontroller niet ideaal voor toepassingen die het volgende vereisen:

• Een permanente naamconventie of opslag.
• Een replica die moet bestaan op elk selecteerknooppunt in een cluster.

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

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

StatefulSets

De ontwikkeling van moderne toepassingen 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 goede, sequentiële benadering voor implementatie, schaal, upgrade en beëindiging. De naamconventie, netwerknamen en opslag blijven bestaan als replica's opnieuw worden gepland met een StatefulSet.

Definieer de toepassing in YAML-indeling met kind: StatefulSet behulp van . Hier 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 bestaan, 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. Om ervoor te 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 of geselecteerde knooppunten. U kunt DaemonSet implementeren op een of meer identieke pods, maar de DaemonSet-controller zorgt ervoor dat elk opgegeven knooppunt een exemplaar van de pod wordt uitgevoerd.

De DaemonSet-controller kan pods op knooppunten vroeg in het opstartproces van het cluster plannen voordat de standaard Kubernetes-scheduler 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 bij StatefulSets wordt een DaemonSet gedefinieerd 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 een naamruimte om een AKS-cluster te verdelen en het maken, weergeven of beheren van toegang tot resources te beperken. U kunt bijvoorbeeld naamruimten maken om bedrijfsgroepen te scheiden. Gebruikers kunnen alleen communiceren met resources binnen hun toegewezen naamruimten.

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

Zie Kubernetes-naamruimten voor meer informatie.

Volgende stappen

In dit artikel worden enkele van de belangrijkste Kubernetes-onderdelen beschreven en wordt beschreven hoe deze van toepassing zijn op AKS-clusters. Zie de volgende artikelen voor meer informatie over kernconcepten van Kubernetes en AKS:

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