Kubernetes-architectuur begrijpen

Laten we Kubernetes-architectuur in detail leren.


Ik neem aan dat je een basiskennis hebt van Kubernetes. Zo niet, bekijk dan de volgende introductie- en installatieartikelen.

Kubernetes-introductie voor beginners

Kubernetes installeren op Ubuntu 18?

Kubernetes volgt master-slave-architectuur. Kubernetes-architectuur heeft een hoofdknooppunt en werkknooppunten. Er zijn vier componenten van een hoofdknooppunt.

  • Kube API-server
  • controller
  • planner
  • enz

En de werkknooppunt heeft drie componenten.

  • kubelet
  • kube-proxy
  • containerlooptijd

Zo ziet een Kubernetes-architectuur eruit:

kubernetes-architectuur

Laat me je in detail vertellen over de componenten van het hoofdknooppunt en de werkknooppunten.

Master Node

Het hoofdknooppunt beheert het Kubernetes-cluster en is het toegangspunt voor alle beheertaken. U kunt via de CLI, GUI of API met het masterknooppunt praten. Om fouttolerantie te bereiken, kan er meer dan één hoofdknooppunt in het cluster zijn. Als we meer dan één masterknooppunt hebben, is er een modus met hoge beschikbaarheid en voert één leider alle bewerkingen uit. Alle andere hoofdknooppunten zouden de volgers zijn van dat hoofdknooppunt.

Om de clusterstatus te beheren, gebruikt Kubernetes etcd. Alle hoofdknooppunten maken verbinding met etcd, een gedistribueerde sleutel / waarde-opslag.

kubernetes hoofdknooppunt

Laat me je één voor één uitleggen over al deze componenten.

API-server

API Server voert alle beheertaken uit op het masterknooppunt. Een gebruiker stuurt de restopdrachten naar de API-server, die vervolgens de verzoeken valideert, vervolgens verwerkt en uitvoert. etcd slaat de resulterende status van het cluster op als een gedistribueerde sleutel / waarde-opslag.

Planner

Daarna hebben we een planner. Zoals de naam al doet vermoeden, plant de planner het werk in op verschillende werkknooppunten. Het heeft de informatie over het gebruik van bronnen voor elk werkknooppunt. De planner houdt ook rekening met de kwaliteit van de servicevereisten, de gegevenslocatie en vele andere dergelijke parameters. Vervolgens plant de planner het werk in termen van pods en services.

Controller Manager

Niet-afsluitende controlelussen die de status van het Kubernetes-cluster regelen, worden beheerd door de Control Manager. Elk van deze controlelussen weet nu van de gewenste status van het object dat het beheert en kijkt vervolgens naar hun huidige status via de API-servers.

Als in een regellus de gewenste toestand niet voldoet aan de huidige toestand van het object, worden de corrigerende stappen genomen door de regellus om de huidige toestand hetzelfde te brengen als de gewenste toestand. De controller-manager zorgt er dus voor dat uw huidige staat dezelfde is als de gewenste staat.

enz

De etcd is een gedistribueerde sleutel / waarde-opslag die wordt gebruikt om de clusterstatus op te slaan. Het moet dus ofwel deel uitmaken van de Kubernetes-master, of u kunt het ook extern configureren. etcd is geschreven in de goLang en is gebaseerd op de Raft consensus algoritme.

Met het vlot kan de verzameling machines werken als een coherente groep die de mislukkingen van sommige van haar leden kan overleven. Zelfs als sommige leden niet werken, kan dit algoritme op elk moment werken. Een van de knooppunten in de groep is de meester en de rest zijn de volgers.

Er kan maar één meester zijn en alle andere meesters moeten die meester volgen. Naast het opslaan van de clusterstatus, wordt etcd ook gebruikt om de configuratiedetails op te slaan, zoals de subnetten en de configuratiekaarten.

Werknemersknooppunt

Een werkerknooppunt is een virtuele of fysieke server die de toepassingen uitvoert en wordt bestuurd door het hoofdknooppunt. De pods zijn gepland op de werkknooppunten, die de nodige tools hebben om ze uit te voeren en te verbinden. Pods zijn niets anders dan een verzameling containers.

En om toegang te krijgen tot de applicaties van de externe wereld, moet u verbinding maken met de werkknooppunten en niet met de hoofdknooppunten.

kubernetes werkknooppunt

Laten we eens kijken naar de componenten van het werkknooppunt.

Containerruntime

De containerruntime wordt in feite gebruikt om een ​​continue levenscyclus op het werkknooppunt uit te voeren en te beheren. Enkele voorbeelden van containerruntimes die ik u kan geven zijn de containers rkt, lxc, enz. Er wordt vaak opgemerkt dat docker ook containerruntime wordt genoemd, maar om precies te zijn, laat me u vertellen dat docker een platform is dat containers gebruikt als de containerruntime.

Kubelet

Kubelet is in feite een agent die op elk werkknooppunt draait en communiceert met het hoofdknooppunt. Dus als u tien werkknooppunten heeft, wordt kubelet op elk werkknooppunt uitgevoerd. Het ontvangt de poddefinitie op verschillende manieren en voert de containers uit die bij die poort horen. Het zorgt er ook voor dat de containers die deel uitmaken van de peulen altijd gezond zijn.

De kubelet maakt verbinding met de runtime van de container met behulp van het gRPC-framework. De kubelet maakt verbinding met de container-runtime-interface (CRI) om containers en beeldbewerkingen uit te voeren. De beeldservice is verantwoordelijk voor alle beeldgerelateerde bewerkingen, terwijl de runtime-service verantwoordelijk is voor alle pod- en containergerelateerde bewerkingen. Deze twee services hebben twee verschillende bewerkingen die moeten worden uitgevoerd.

Laat me je iets interessants vertellen, container-runtimes waren vroeger hard gecodeerd in Kubernetes, maar met de ontwikkeling van CRI kunnen Kubernetes nu verschillende container-runtimes gebruiken zonder dat ze opnieuw hoeven te worden gecompileerd. Dus elke containerruntime die CRI implementeert, kan door Kubernetes worden gebruikt om pods, containers en containerimages te beheren. Docker shim en CRI-containers zijn twee voorbeelden van CRI shim. Met docker shim worden containers gemaakt met docker die op de werkknooppunten is geïnstalleerd en vervolgens gebruikt docker intern een container om containers te maken en te beheren

Kube-proxy

Kube-proxy draait op elk werkknooppunt als netwerkproxy. Het luistert naar de API-server voor het maken of verwijderen van elk servicepunt. Voor elk servicepunt stelt kube-proxy de routes in zodat deze deze kan bereiken.

Conclusie

Ik hoop dat dit je helpt om Kubernetes-architectuur beter te begrijpen. Kubernetes-vaardigheden zijn altijd op aanvraag en als je op zoek bent om te leren hoe je een carrière kunt opbouwen, bekijk dit dan Udemy natuurlijk.

TAGS:

  • Docker

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map