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

Artikel
11/23/2024

Van toepassing op: AKS in Azure Local 22H2, AKS op Windows Server

Azure Kubernetes Service (AKS) op Azure Local en Windows Server is een kubernetes-containerplatform op bedrijfsniveau dat wordt mogelijk gemaakt door Azure Local. 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 belangrijkste Kubernetes-infrastructuuronderdelen geïntroduceerd, zoals het besturingsvlak, knooppunten en knooppuntgroepen. Workloadresources, zoals pods, implementaties en sets, worden ook geïntroduceerd, samen met het groeperen van resources in naamruimten.

Kubernetes-clusterarchitectuur

Kubernetes is het kernonderdeel van AKS dat is ingeschakeld door Azure Arc. AKS maakt gebruik van een set vooraf gedefinieerde configuraties om Kubernetes-clusters effectief en met schaalbaarheid in gedachten te implementeren.

Met de implementatiebewerking worden meerdere virtuele Linux- of Windows-machines gemaakt en samengevoegd om Kubernetes-clusters te maken.

Notitie

Als u meerdere CSV's (Cluster Shared Volumes) in uw cluster uitvoert, worden standaard gegevens van virtuele machines automatisch verspreid 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 bekend als de AKS-host) biedt het kernindelingsmechanisme en de interface voor het implementeren en beheren van een of meer workloadclusters.
Workloadclusters (ook wel doelclusters genoemd) zijn waar containertoepassingen worden geïmplementeerd.

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 voor het beheren van de levenscyclus van clusters.
Met een PowerShell-module kunt u AKS eenvoudig downloaden, configureren en implementeren. De PowerShell-module ondersteunt ook het implementeren en configureren van andere workloadclusters en het opnieuw configureren van bestaande clusters.

Het beheercluster

Wanneer u een Kubernetes-cluster maakt, wordt 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 kernonderdelen van Kubernetes:

API-server: de API-server is hoe 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. Op Windows Server Core gebaseerde VM's worden gebruikt voor het tot stand brengen van Windows-werkknooppunten. Er kunnen een of meer workloadclusters worden beheerd door één beheercluster.

Onderdelen van workloadcluster

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

Besturingsvlak

API-server: de API-server maakt interactie mogelijk met de Kubernetes-API. 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. De status van het besturingsvlak wordt opgeslagen.

Load balancer

De load balancer is een virtuele machine waarop Linux en HAProxy + KeepAlive worden uitgevoerd 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 dat op het workloadcluster wordt gemaakt, maakt uiteindelijk een taakverdelingsregel in de VIRTUELE machine.

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 Onderdelen van het Kubernetes-knooppunt worden uitgevoerd en hosten de pods en services waaruit de workload van de toepassing bestaat.

Er zijn kernonderdelen voor Kubernetes-werkbelastingen die kunnen worden geïmplementeerd op AKS-workloadclusters, zoals pods en implementaties.

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, 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 stellen containers in staat gerelateerde resources te delen. Zie Kubernetes-pods en kubernetes-podlevenscyclus voor meer informatie.

Installaties

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-scheduler zorgt ervoor dat als pods of knooppunten problemen ondervinden, extra pods worden gepland op knooppunten die in orde zijn. 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 de verdeling van replica's over de knooppunten.

StatefulSets: een StatefulSet is vergelijkbaar met een implementatie waarin een of meer identieke pods worden gemaakt en beheerd. Replica's in een StatefulSet volgen een elegante, opeenvolgende benadering voor implementatie, schaal, upgrades en beëindigingen. Met een StatefulSet (als replica's opnieuw worden gepland) blijft 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 logboekverzamelingen 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 knooppunt dat is opgegeven 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 te beperken tot het maken, weergeven of beheren van resources. 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 die is ingeschakeld door Arc, zijn de volgende naamruimten beschikbaar:

standaard: een naamruimte waarin 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: een naamruimte 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: een naamruimte die doorgaans niet wordt gebruikt, maar kan worden gebruikt voor resources om zichtbaar te zijn 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 standaard geheimen op als niet-versleutelde met base64 gecodeerde tekenreeksen en ze 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 dat is ingericht door de beheerder of dynamisch is ingericht met behulp van opslagklassen. Als u permanente volumes wilt gebruiken, vraagt pods toegang aan met behulp van een PersistentVolumeClaim. Zie Permanente volumes voor meer informatie.

Implementaties met meerdere besturingssystemen

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

Knooppuntkiezer is een eenvoudig veld in de podspecificatie waarmee pods alleen worden gepland op gezonde knooppunten die overeenkomen met het besturingssysteem.
Taints en toleranties werken samen om ervoor te zorgen dat pods niet per ongeluk op knooppunten worden gepland. Een knooppunt kan 'tainted' zijn, zodat 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 is ingeschakeld door Azure Arc en de onderdelen van het workloadcluster. Zie de volgende artikelen voor meer informatie over deze concepten:

Delen via