Hoe Kubernetes werkt

Voltooid

Een correct geconfigureerde Kubernetes-installatie is afhankelijk van een gedegen begrip van de Kubernetes-systeemarchitectuur. Hier bekijkt u alle onderdelen waaruit een Kubernetes-installatie bestaat.

Wat is een computercluster?

Een cluster is een set computers die u zo configureert dat ze samenwerken en als één systeem worden weergegeven. De computers die in het cluster zijn geconfigureerd, verwerken dezelfde soorten taken. Ze hosten bijvoorbeeld allemaal websites of API's, of voeren gegevensverwerkingstaken met een hoge belasting uit.

Een cluster gebruikt gecentraliseerde software die verantwoordelijk is voor het plannen en beheren van deze taken. De computers in een cluster waarop de taken worden uitgevoerd, worden knooppunten genoemd en de computers waarop de planningssoftware wordt uitgevoerd, worden besturingsvlakken genoemd.

Kubernetes-architectuur

Zoals u weet, is een orchestrator een systeem dat apps implementeert en beheert. U hebt ook geleerd dat een cluster een set computers is die samenwerken en als één systeem worden bekeken. U gebruikt Kubernetes als de indelings- en clustersoftware om uw apps te implementeren en te reageren op wijzigingen in de behoeften van rekenresources.

Een Kubernetes-cluster bevat ten minste één hoofdbesturingsvlak en een of meer knooppunten. Zowel de besturingsvlakken als de knooppuntinstanties kunnen fysieke apparaten, virtuele machines of exemplaren in de cloud zijn. Het standaardhostbesturingssysteem in Kubernetes is Linux, met standaardondersteuning voor op Linux gebaseerde workloads.

U kunt ook Microsoft-workloads uitvoeren met Windows Server 2019 of hoger op clusterknooppunten. Stel dat de gegevensverwerkingsservice in de app voor het traceren van drones is geschreven als een .NET 4.5-app die gebruikmaakt van specifieke Api-aanroepen van Windows OS. Deze service kan alleen worden uitgevoerd op knooppunten waarop een Windows Server-besturingssysteem wordt uitgevoerd.

Laten we nu kijken naar zowel de besturingsvlakken als werkknooppunten en de software die op elk van deze knooppunten wordt uitgevoerd. Wanneer u Kubernetes gaat installeren, is het handig dat u de rol van elk onderdeel snapt en begrijpt waar elk onderdeel in het cluster wordt uitgevoerd.

Kubernetes-besturingsvlak

Het Kubernetes-besturingsvlak in een Kubernetes-cluster voert een verzameling services uit die de indelingsfunctionaliteit in Kubernetes beheert.

Vanuit een leerperspectief is het zinvol om één besturingsvlak in uw testomgeving te gebruiken bij het verkennen van de Kubernetes-functionaliteit. In productie- en cloudimplementaties zoals Azure Kubernetes Service (AKS) vindt u echter dat de voorkeursconfiguratie een implementatie met hoge beschikbaarheid is met drie tot vijf gerepliceerde besturingsvlakken.

Notitie

Het feit dat op een besturingsvlak specifieke software wordt uitgevoerd om de status van het cluster te behouden, sluit niet uit dat het andere rekenworkloads uitvoert. Doorgaans willen we echter het besturingsvlak uitsluiten van niet-essentiële workloads en van workloads voor gebruikers-apps.

Kubernetes-knooppunt

Een knooppunt in een Kubernetes-cluster is het punt waar uw rekenworkloads worden uitgevoerd. Elk knooppunt communiceert met het besturingsvlak via de API-server om deze te informeren over statuswijzigingen op het knooppunt.

Services die worden uitgevoerd in een besturingsvlak

Kubernetes is afhankelijk van verschillende beheerservices die op het besturingsvlak worden uitgevoerd. Deze services beheren aspecten zoals communicatie van clusteronderdelen, workloadplanning en persistentie van de clusterstatus.

De volgende services vormen het besturingsvlak van een Kubernetes-cluster:

• API-server
• Externe opslag
• Planner
• Controllermanager
• Cloudcontrollermanager

Wat is de API-server?

U kunt de API-server beschouwen als de front-end van het besturingsvlak van uw Kubernetes-cluster. Alle communicatie tussen de onderdelen in Kubernetes verloopt via deze API.

Als gebruiker gebruikt u bijvoorbeeld een opdrachtregel-app met de naam kubectl waarmee u opdrachten kunt uitvoeren op de API-server van uw Kubernetes-cluster. Het onderdeel dat deze API levert, wordt kube-apiserver genoemd. U kunt meerdere instanties van dit onderdeel implementeren om het schalen in uw cluster te ondersteunen.

Deze API maakt een RESTful-API beschikbaar, waarmee u opdrachten of YAML-configuratiebestanden kunt posten. YAML is een leesbare standaard voor het serialiseren van gegevens voor programmeertalen. U gebruikt YAML-bestanden om de beoogde status te definiëren van alle objecten in een Kubernetes-cluster.

Stel dat u het aantal instanties van uw app in het cluster wilt verhogen. U definieert de nieuwe status met een YAML-bestand en verzendt dit bestand naar de API-server. De API-server valideert de configuratie, slaat deze op in het cluster en voert ten slotte de geconfigureerde toename in app-implementaties uit.

Wat is de externe opslag?

Het back-uparchief is een permanente opslag waarin uw Kubernetes-cluster de voltooide configuratie opslaat. Kubernetes maakt gebruik van een gedistribueerde, betrouwbare sleutel-waardeopslag met hoge beschikbaarheid, met de naam etcd. In deze sleutelwaardeopslag worden de huidige status en de gewenste status van alle objecten in uw cluster opgeslagen.

In een Kubernetes-cluster voor een productieomgeving is de officiële Kubernetes-richtlijn dat u over drie tot vijf gerepliceerde instanties van de etcd-database moet beschikken voor hoge beschikbaarheid.

Notitie

etcd is niet verantwoordelijk voor gegevensback-up. Het is uw verantwoordelijkheid om ervoor te zorgen dat er een effectief back-upplan aanwezig is om een back-up te maken van de etcd-gegevens.

Wat is de planner?

De planner is het onderdeel dat verantwoordelijk is voor de toewijzing van workloads op alle knooppunten. De planner controleert het cluster op recent gemaakte containers en wijst deze toe aan knooppunten.

Wat is de controllermanager?

De controllermanager start en bewaakt de controllers die zijn geconfigureerd voor een cluster via de API-server.

Kubernetes gebruikt controllers om objectstatussen in het cluster bij te houden. Elke controller wordt uitgevoerd in een niet-terminerende lus tijdens het bekijken en reageren op gebeurtenissen in het cluster. Er zijn bijvoorbeeld controllers om onder andere knooppunten, containers en eindpunten te controleren.

De controller communiceert met de API-server om de status van het object te bepalen. Als de huidige status verschilt van de gewenste status van het object, neemt de controller actie om de gewenste status te garanderen.

Stel dat een van de drie containers die in uw cluster worden uitgevoerd, niet meer reageert en mislukt. In dat geval beslist een controller of u nieuwe containers moet starten om ervoor te zorgen dat uw apps altijd beschikbaar zijn. Als de gewenste staat is om op elk moment drie containers uit te voeren, wordt een nieuwe container ingepland om te worden uitgevoerd.

Wat is de cloudcontrollermanager?

De cloudcontrollermanager is geïntegreerd met de onderliggende cloudtechnologieën in uw cluster wanneer het cluster wordt uitgevoerd in een cloudomgeving. Deze services kunnen bijvoorbeeld load balancers, wachtrijen en opslag zijn.

Services die worden uitgevoerd in een knooppunt

Er zijn verschillende services die worden uitgevoerd op een Kubernetes-knooppunt om te bepalen hoe workloads worden uitgevoerd.

De volgende services worden uitgevoerd op het Kubernetes-knooppunt:

• Kubelet
• Kube-proxy
• Container-runtime

Wat is de kubelet?

De kubelet is de agent die op elk knooppunt in het cluster wordt uitgevoerd en die werkaanvragen van de API-server controleert. Het zorgt ervoor dat de aangevraagde werkeenheid wordt uitgevoerd en in goede staat is.

De kubelet controleert de knooppunten en zorgt ervoor dat de containers die voor elk knooppunt zijn gepland volgens verwachting worden uitgevoerd. De kubelet beheert alleen containers die door Kubernetes worden gemaakt. Het is niet verantwoordelijk voor het opnieuw plannen van werkzaamheden zodat deze worden uitgevoerd op andere knooppunten als het huidige knooppunt de werkzaamheden niet kan uitvoeren.

Wat is kube-proxy?

Het onderdeel kube-proxy is verantwoordelijk voor lokale clusternetwerken en wordt op elk knooppunt uitgevoerd. Het zorgt ervoor dat elk knooppunt een uniek IP-adres heeft. Het implementeert ook regels voor de routering en taakverdeling van verkeer met behulp van iptables en IPVS.

Deze proxy biedt zelf geen DNS-services. Een DNS-clusterinvoegtoepassing op basis van CoreDNS wordt aanbevolen en wordt standaard geïnstalleerd.

Wat is de container-runtime?

De container-runtime is de onderliggende software waarmee containers worden uitgevoerd in een Kubernetes-cluster. De runtime is verantwoordelijk voor het ophalen, starten en stoppen van containerinstallatiekopieën. Kubernetes ondersteunt verschillende containerruntimes, waaronder maar niet beperkt tot Docker, containerd, rkt, CRI-O en frakti. De ondersteuning voor veel container-runtimetypen is gebaseerd op de Container Runtime Interface (CRI). De CRI is een invoegtoepassing waardoor de kubelet kan communiceren met de beschikbare container-runtime.

De standaardcontainerruntime in AKS is een container, een industriestandaard containerruntime.

Interactie met een Kubernetes-cluster

Kubernetes biedt een opdrachtregelprogramma met de naam kubectl om uw cluster te beheren. U gebruikt kubectl om opdrachten te verzenden naar het besturingsvlak van het cluster of om informatie over alle Kubernetes-objecten op te halen via de API-server.

kubectl maakt gebruik van een configuratiebestand dat de volgende configuratiegegevens bevat:

• Met de configuratie Cluster geeft u een clusternaam, certificaatgegevens en het service-API-eindpunt voor het cluster op. Met deze definitie kunt u vanaf één werkstation verbinding maken met meerdere clusters.
• Met de configuratie Gebruiker geeft u de gebruikers en hun machtigingsniveaus op wanneer ze toegang verkrijgen tot de geconfigureerde clusters.
• Contextconfiguratiegroepen clusters en gebruikers met behulp van een beschrijvende naam. U kunt bijvoorbeeld een 'dev-cluster' en een 'prod-cluster' gebruiken om uw ontwikkelings- en productieclusters aan te duiden.

U kunt kubectl configureren om verbinding te maken met meerdere clusters door de juiste context op te geven als onderdeel van de opdrachtregelsyntaxis.

Kubernetes-pods

Een pod vertegenwoordigt één exemplaar van een app die wordt uitgevoerd in Kubernetes. De workloads die u op Kubernetes uitvoert, zijn in containers geplaatste apps. In tegenstelling tot de Docker-omgeving kunt u containers niet rechtstreeks in Kubernetes uitvoeren. U kunt de container inpakken in een Kubernetes-object, ook wel een pod genoemd. Een pod is het kleinste object dat u in Kubernetes kunt maken.

Eén pod kan een groep van een of meer containers bevatten. Een pod bevat normaal gesproken echter geen veelvouden van dezelfde app.

Een pod bevat informatie over de gedeelde opslag- en netwerkconfiguratie en een specificatie over het uitvoeren van de verpakte containers. U gebruikt podsjablonen om de informatie te definiëren over de pods die in uw cluster worden uitgevoerd. Podsjablonen zijn bestanden met YAML-code die u opnieuw gebruikt en in andere objecten opneemt om podimplementaties te beheren.

Stel dat u een website wilt implementeren in een Kubernetes-cluster. U maakt het poddefinitiebestand waarin de containerinstallatiekopieën en configuratie van de app worden opgegeven. Vervolgens implementeert u het poddefinitiebestand in Kubernetes.

Het is niet waarschijnlijk dat een web-app een website bevat als het enige onderdeel in de oplossing. Een web-app heeft normaal gesproken een soort gegevensopslag en andere ondersteunende elementen. Kubernetes-pods kunnen ook meer dan één container bevatten.

Stel dat uw site gebruikmaakt van een database. De website is verpakt in de hoofdcontainer en de database is verpakt in de ondersteunende container. Meerdere containers communiceren met elkaar via een omgeving. De containers bevatten services voor een host-besturingssysteem, netwerkstack, kernelnaamruimte, gedeeld geheugen en opslagvolume. De pod is de sandbox-omgeving die al deze services levert aan uw app. De pod stelt de containers ook in staat om hun toegewezen IP-adres te delen.

Omdat u eventueel veel pods maakt die worden uitgevoerd op veel knooppunten, kan het lastig zijn om ze te identificeren. U kunt pods herkennen en groeperen met tekenreekslabels die u opgeeft wanneer u een pod definieert.

De levenscyclus van een Kubernetes-pod

Kubernetes-pods hebben een unieke levenscyclus die van invloed is op de manier waarop u pods implementeert, uitvoert en bijwerkt. U begint met het verzenden van het YAML-manifest van de pod naar het cluster. Nadat het manifestbestand is verzonden en opgeslagen in het cluster, wordt de gewenste status van de pod gedefinieerd. Met de planner wordt de pod gepland op een goed werkend knooppunt dat over voldoende resources beschikt om de pod uit te voeren.

De levenscyclus van een pod bestaat uit de volgende fasen:

Fase	Beschrijving
In behandeling	De pod accepteert het cluster, maar niet alle containers in het cluster zijn ingesteld of klaar om te worden uitgevoerd. De status In behandeling geeft aan hoe lang een pod moet worden gepland en de tijd die nodig is om containerinstallatiekopieën te downloaden.
Wordt uitgevoerd	De pod gaat over naar de status Wordt uitgevoerd wanneer alle resources in de pod gereed zijn.
Geslaagd	De pod gaat over naar de status Geslaagd wanneer de pod de beoogde taak heeft voltooid en wordt uitgevoerd.
Mislukt	Pods kunnen om verschillende redenen mislukken. Een container in de pod kan mislukken, wat leidt tot beëindiging van alle andere containers of misschien is er geen installatiekopieën gevonden tijdens de voorbereiding van de podcontainers. In dit soort gevallen kan de pod naar de status Mislukt gaan. Pods kunnen worden overgestapt op een status Mislukt van een status In behandeling of van de status Actief. Door een specifieke fout kan een pod ook worden teruggezet naar de status In behandeling.
Onbekend	Als de status van de pod niet kan worden bepaald, heeft de pod de status Onbekend.

Pods worden op een cluster bewaard totdat een controller, het besturingsvlak of een gebruiker ze expliciet verwijdert. Wanneer een pod wordt verwijderd, wordt er direct daarna een nieuwe pod gemaakt. De nieuwe pod wordt beschouwd als een volledig nieuw exemplaar op basis van het podmanifest. Het is geen exacte kopie, dus het verschilt van de verwijderde pod.

Het cluster slaat de status of de dynamisch toegewezen configuratie van de pod niet op. Het slaat bijvoorbeeld de id of het IP-adres van de pod niet op. Dit aspect heeft invloed op de wijze waarop u pods implementeert en uw apps ontwerpt. U kunt bijvoorbeeld niet vertrouwen op vooraf toegewezen IP-adressen voor uw pods.

Containerstatussen

Bedenk dat de fasen een samenvatting zijn van waar in de levenscyclus de pod zich bevindt. Wanneer u een pod inspecteert, gebruikt het cluster drie statussen om uw containers in de pod bij te houden:

Toestand	Beschrijving
In afwachting	De standaardstatus van een container en de status waarin de container zich bevindt wanneer deze niet wordt uitgevoerd of is beëindigd.
Wordt uitgevoerd	De container wordt zoals verwacht uitgevoerd zonder problemen.
Beëindigd	De container wordt niet meer uitgevoerd. De reden hiervoor is dat alle taken zijn voltooid of dat de container om een of andere reden is mislukt. Er zijn een reden- en afsluitcode beschikbaar voor het opsporen van fouten in beide gevallen.