Kubernetes-clusterarchitectuur en -workloads voor AKS die worden ingeschakeld door Azure Arc

Van toepassing op: AKS op Azure Stack HCI 22H2, AKS op Windows Server

Azure Kubernetes Service (AKS) op Azure Stack HCI en Windows Server is een Kubernetes-containerplatform op bedrijfsniveau dat mogelijk wordt gemaakt door Azure Stack HCI. Het bevat door Microsoft ondersteunde kern-Kubernetes, een speciaal gebouwde Windows-containerhost en een door Microsoft ondersteunde Linux-containerhost, met als doel een eenvoudige implementatie- en levenscyclusbeheerervaring te hebben.

In dit artikel worden de kernonderdelen van de Kubernetes-infrastructuur geïntroduceerd, zoals het besturingsvlak, knooppunten en knooppuntgroepen. Workloadresources zoals pods, implementaties en sets worden ook geïntroduceerd, samen met hoe u resources in naamruimten groepeert.

Kubernetes-clusterarchitectuur

Kubernetes is het kernonderdeel van AKS dat wordt ingeschakeld door Azure Arc. AKS maakt gebruik van een set vooraf gedefinieerde configuraties om Kubernetes-cluster(s) effectief en met het oog op schaalbaarheid te implementeren.

Tijdens de implementatiebewerking worden meerdere virtuele Linux- of Windows-machines gemaakt en worden deze samengevoegd om Kubernetes-cluster(s) te maken.

Notitie

Als u meerdere CSV's (Cluster Shared Volumes) in uw cluster uitvoert, worden de gegevens van virtuele machines standaard automatisch verdeeld over alle beschikbare CSV's in het cluster om de betrouwbaarheid van het systeem te verbeteren. Dit zorgt ervoor dat toepassingen overleven in het geval van CSV-storingen. Dit geldt alleen voor nieuwe installaties (geen upgrades).

Het geïmplementeerde systeem is klaar om standaard Kubernetes-workloads te ontvangen, deze workloads te schalen of zelfs het aantal virtuele machines en het aantal clusters naar behoefte omhoog en omlaag te schalen.

Een Azure Kubernetes Service cluster heeft de volgende onderdelen:

  • Beheercluster (ook wel de AKS-host genoemd) biedt het mechanisme en de interface voor de kernindeling voor het implementeren en beheren van een of meer workloadclusters.
  • Workloadclusters (ook wel doelclusters genoemd) zijn de plek waar containertoepassingen worden geïmplementeerd.

Afbeelding van de technische architectuur van Azure Kubernetes Service op Azure Stack HCI en Windows Server.

AKS beheren die is ingeschakeld door Arc

U kunt AKS beheren met behulp van de volgende beheeropties:

  • Windows Admin Center biedt een intuïtieve gebruikersinterface voor de Kubernetes-operator om de levenscyclus van clusters te beheren.
  • Met een PowerShell-module kunt u eenvoudig AKS downloaden, configureren en implementeren. De PowerShell-module ondersteunt ook het implementeren en configureren van andere workloadclusters en het opnieuw configureren van bestaande workloadclusters.

Het beheercluster

Wanneer u een Kubernetes-cluster maakt, wordt er automatisch een beheercluster gemaakt en geconfigureerd. Dit beheercluster is verantwoordelijk voor het inrichten en beheren van workloadclusters waar workloads worden uitgevoerd. Een beheercluster bevat de volgende kubernetes-kernonderdelen:

  • API-server: de API-server is de wijze waarop de onderliggende Kubernetes-API's worden weergegeven. Dit onderdeel biedt de interactie voor beheerhulpprogramma's, zoals Windows Admin Center, PowerShell-modules of kubectl.
  • Load balancer: de load balancer is één toegewezen Linux-VM met een taakverdelingsregel voor de API-server van het beheercluster.

Het workloadcluster

Het workloadcluster is een maximaal beschikbare implementatie van Kubernetes met behulp van Linux-VM's voor het uitvoeren van Kubernetes-besturingsvlakonderdelen en Linux-werkknooppunten. Windows Server Core-VM's worden gebruikt voor het tot stand brengen van Windows-werkknooppunten. Er kunnen een of meer workloadclusters zijn die worden beheerd door één beheercluster.

Onderdelen van workloadclusters

Het workloadcluster bevat veel onderdelen, die in de volgende secties worden beschreven.

Besturingsvlak

  • API-server: de API-server staat interactie met de Kubernetes-API toe. Dit onderdeel biedt de interactie voor beheerhulpprogramma's, zoals Windows Admin Center, PowerShell-modules of kubectl.
  • Etcd: Etcd is een gedistribueerd sleutel-waardearchief waarin gegevens worden opgeslagen die nodig zijn voor levenscyclusbeheer van het cluster. Hiermee wordt de status van het besturingsvlak opgeslagen.

Load balancer

De load balancer is een virtuele machine met Linux en HAProxy + KeepAlive om services met gelijke taakverdeling te bieden voor de workloadclusters die door het beheercluster zijn geïmplementeerd. Voor elk workloadcluster voegt AKS ten minste één virtuele load balancer-machine toe. Elke Kubernetes-service van het type LoadBalancer die in het workloadcluster wordt gemaakt, maakt uiteindelijk een taakverdelingsregel in de VM.

Werkknooppunten

Als u uw toepassingen en ondersteunende services wilt uitvoeren, hebt u een Kubernetes-knooppunt nodig. Een AKS-workloadcluster heeft een of meer werkknooppunten. Werkknooppunten fungeren als virtuele machines (VM's) waarop de Kubernetes-knooppuntonderdelen worden uitgevoerd en hosten de pods en services waaruit de toepassingsworkload bestaat.

Er zijn belangrijke Kubernetes-workloadonderdelen die kunnen worden geïmplementeerd op AKS-workloadclusters, zoals pods en implementaties.

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, hoewel er geavanceerde scenario's zijn waarin een pod meerdere containers kan bevatten. Deze pods met meerdere containers worden samen gepland op hetzelfde knooppunt en kunnen containers gerelateerde resources delen. Zie Kubernetes-pods en levenscyclus van Kubernetes-pods voor meer informatie.

Implementaties

Een implementatie vertegenwoordigt een of meer identieke pods, die worden beheerd door de Kubernetes-implementatiecontroller. Een implementatie definieert het aantal replica's (pods) dat moet worden gemaakt en de Kubernetes-planner zorgt ervoor dat als pods of knooppunten problemen ondervinden, er extra pods worden gepland op knooppunten met een goede status. Zie Kubernetes-implementaties voor meer informatie.

StatefulSets en DaemonSets

De implementatiecontroller gebruikt de Kubernetes-planner om een bepaald aantal replica's uit te voeren op elk beschikbaar knooppunt met beschikbare resources. Deze benadering van het gebruik van implementaties is mogelijk voldoende voor staatloze toepassingen, maar niet voor toepassingen waarvoor een permanente naamconventie of opslag is vereist. Voor toepassingen waarvoor een replica moet bestaan op elk knooppunt (of geselecteerde knooppunten) in een cluster, kijkt de implementatiecontroller niet naar hoe replica's over de knooppunten worden gedistribueerd.

  • StatefulSets: een StatefulSet is vergelijkbaar met een implementatie, omdat een of meer identieke pods worden gemaakt en beheerd. Replica's in een StatefulSet volgen een elegante, sequentiële benadering voor implementatie, schaalaanpassing, upgrades en beëindigingen. Met een StatefulSet (als replica's opnieuw worden gepland) blijven de naamconventie, netwerknamen en opslag behouden. Replica's in een StatefulSet worden gepland en uitgevoerd op elk beschikbaar knooppunt in een Kubernetes-cluster. Als u ervoor wilt zorgen dat ten minste één pod in uw set wordt uitgevoerd op een knooppunt, kunt u in plaats daarvan een DaemonSet gebruiken. Zie Kubernetes StatefulSets voor meer informatie.
  • DaemonSets: voor specifieke logboekverzamelings- of bewakingsbehoeften moet u mogelijk een bepaalde pod uitvoeren op alle of geselecteerde knooppunten. Een DaemonSet wordt opnieuw gebruikt om een of meer identieke pods te implementeren, maar de DaemonSet-controller zorgt ervoor dat elk opgegeven knooppunt een exemplaar van de pod uitvoert. Zie Kubernetes DaemonSets voor meer informatie.

Naamruimten

Kubernetes-resources, zoals pods en implementaties, worden logisch gegroepeerd in een naamruimte. Deze groeperingen bieden een manier om workloadclusters logisch te verdelen en de toegang tot het maken, weergeven of beheren van resources te beperken. U kunt bijvoorbeeld naamruimten maken om bedrijfsgroepen van elkaar te scheiden. Gebruikers kunnen alleen communiceren met resources binnen de aan hen toegewezen naamruimten. Zie Kubernetes-naamruimten voor meer informatie.

Wanneer u een Azure Kubernetes Service-cluster maakt op AKS dat wordt ingeschakeld door Arc, zijn de volgende naamruimten beschikbaar:

  • standaard: een naamruimte waar pods en implementaties standaard worden gemaakt wanneer er geen pods worden opgegeven. In kleinere omgevingen kunt u toepassingen rechtstreeks in de standaardnaamruimte implementeren zonder extra logische scheidingen 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: een naamruimte waarin kernresources aanwezig zijn, zoals netwerkfuncties zoals DNS en proxy, of het Kubernetes-dashboard. Doorgaans implementeert u uw eigen toepassingen niet in deze naamruimte.
  • kube-public: een naamruimte die doorgaans niet wordt gebruikt, maar kan worden gebruikt om resources zichtbaar te maken in het hele cluster en kan door elke gebruiker worden bekeken.

Geheimen

Met Kubernetes-geheimen kunt u gevoelige informatie opslaan en beheren, zoals wachtwoorden, OAuth-tokens en SSH-sleutels (Secure Shell). Kubernetes slaat geheimen standaard op als niet-versleutelde base64-gecodeerde tekenreeksen en kunnen worden opgehaald als tekst zonder opmaak door iedereen met API-toegang. Zie Kubernetes Secrets voor meer informatie.

Permanente volumes

Een permanent volume is een opslagresource in een Kubernetes-cluster die is ingericht door de beheerder of dynamisch is ingericht met behulp van opslagklassen. Als u permanente volumes wilt gebruiken, vragen pods toegang aan met behulp van een PersistentVolumeClaim. Zie Permanente volumes voor meer informatie.

Implementaties met gemengde besturingssystemen

Als een bepaald workloadcluster bestaat uit zowel Linux- als Windows-werkknooppunten, moet het worden gepland op een besturingssysteem dat ondersteuning kan bieden voor het inrichten van de workload. Kubernetes biedt twee mechanismen om ervoor te zorgen dat workloads terechtkomen op knooppunten met een doelbesturingssysteem:

  • Knooppuntkiezer is een eenvoudig veld in de podspecificatie waarmee wordt beperkt dat pods alleen worden gepland op gezonde knooppunten die overeenkomen met het besturingssysteem.
  • Taints en toleranties werken samen om ervoor te zorgen dat pods niet onbedoeld op knooppunten worden gepland. Een knooppunt kan zodanig worden 'bevlekt' dat het geen pods accepteert die de taint niet expliciet tolereren via een 'tolerantie' in de podspecificatie.

Zie knooppuntkiezers en taints en toleranties voor meer informatie.

Volgende stappen

In dit artikel hebt u geleerd over de clusterarchitectuur van AKS die wordt ingeschakeld door Azure Arc en de onderdelen van het workloadcluster. Zie de volgende artikelen voor meer informatie over deze concepten: