Kubernetes-zelfstudie - een uitgebreide gids voor Kubernetes



Deze blog over Kubernetes-zelfstudie leidt u door alle concepten van het containerorkestratiesysteem met een hands-on.

Kubernetes is een platform dat de handmatige processen elimineert die betrokken zijn bij het implementeren van gecontaineriseerde applicaties. In deze blog over Kubernetes-zelfstudie bespreek je alle concepten met betrekking tot deze multi-container beheeroplossing.

In deze tutorial komen de volgende onderwerpen aan bod:





Voordat ik verder ga in deze blog, wil ik u even kort informeren over containerisatie.

Dus voordat containers ontstonden, hadden de ontwikkelaars en de testers altijd een ruzie tussen hen. Dit gebeurde meestal omdat wat werkte aan de ontwikkelaarskant, niet zou werken aan de testkant. Beiden bestonden in verschillende omgevingen. Om dergelijke scenario's te vermijden, werden containers geïntroduceerd zodat zowel de ontwikkelaars als de testers op dezelfde pagina zaten.



fibonacci c ++ recursie

Het was ook een probleem om een ​​groot aantal containers samen te behandelen. Soms kwamen er tijdens het draaien van containers aan de productzijde weinig issues naar voren die in de ontwikkelingsfase niet aanwezig waren. Dit soort scenario's introduceerde het Container Orchestration System.

Voordat ik diep in het orkestratiesysteem duik, wil ik even snel een lijst maken van de uitdagingen waarmee ik te maken heb zonder dit systeem.



Kubernetes-zelfstudie: uitdagingen zonder containerorkestratie

Uitdagingen zonder containerorkestratie - Kubernetes-zelfstudie - Edureka

Zoals u in het bovenstaande diagram kunt zien wanneer meerdere services in containers worden uitgevoerd, wilt u deze containers misschien schalen. In grootschalige industrieën is dit erg moeilijk om te doen. Dat komt omdat het de kosten voor het onderhouden van services zou verhogen en de complexiteit om ze naast elkaar te laten draaien.

Om het handmatig opzetten van services te vermijden en de uitdagingen te overwinnen, was er iets groots nodig. Dit is waar Container Orchestration Engine in beeld komt.

Met deze engine kunnen we meerdere containers zo organiseren dat alle onderliggende machines worden gelanceerd, containers gezond zijn en gedistribueerd in een geclusterde omgeving. In de wereld van vandaag zijn er hoofdzakelijk twee van dergelijke motoren: Gouverneurs & Docker Swarm .

Kubernetes-zelfstudie: Kubernetes versus Docker Swarm

Gouverneurs en Docker Swarm zijn toonaangevende tools voor containerorkestratie in de huidige markt. Dus voordat u ze in prod gebruikt, moet u weten wat ze precies zijn en hoe ze werken.

Verder ga ik in de blog diep in Kubernetes duiken, maar om meer te weten over Docker kun je klikken .

Zoals je naar de bovenstaande afbeelding kunt verwijzen, bezit Kubernetes, vergeleken met Docker Swarm, een geweldige actieve community en maakt het automatisch schalen mogelijk in veel organisaties. Evenzo heeft Docker Swarm een ​​eenvoudig te starten cluster in vergelijking met Kubernetes, maar het is beperkt tot de mogelijkheden van de Docker API.

Nou, mensen, dit zijn niet de enige verschillen tussen deze toptools. Als u de gedetailleerde verschillen tussen deze beide containerorkestratietools wilt weten, klikt u op

Wilt u meer weten over Kubernetes?

Als ik mijn keuze tussen de twee zou kunnen kiezen, dan zou het Kubernetes moeten zijn, aangezien containers moeten worden beheerd en verbonden met de buitenwereld voor taken zoals planning, load balancing en distributie.

Maar als je logisch denkt, zou Docker Swarm een ​​betere optie zijn, omdat het bovenop Docker draait, toch? Als ik jou was, zou ik zeker in de war zijn geraakt over welke tool ik moest gebruiken. Maar goed, Kubernetes is een onbetwiste leider in de markt en draait ook op Docker-containers met betere functionaliteiten.

Nu je de noodzaak van Kubernetes hebt begrepen, is het een goed moment, dat vertel ik je Wat is Kubernetes?

Kubernetes-zelfstudie: Wat is Kubernetes?

is een open-source systeem dat het werk van het plannen van containers op een rekencluster afhandelt en de workloads beheert om ervoor te zorgen dat ze worden uitgevoerd zoals de gebruiker het bedoeld heeft. Als het geesteskind van Google biedt het een uitstekende community en werkt het uitstekend samen met alle cloudproviders om een multi-container beheeroplossing.

Kubernetes-zelfstudie: Kubernetes-functies

De kenmerken van Kubernetes zijn als volgt:

  • Geautomatiseerde planning: Kubernetes biedt een geavanceerde planner om containers op clusterknooppunten te lanceren op basis van hun resourcevereisten en andere beperkingen, zonder afbreuk te doen aan de beschikbaarheid.
  • Zelfherstellende mogelijkheden: Kubernetes maakt het mogelijk om containers te vervangen en opnieuw te plannen wanneer knooppunten doodgaan. Het doodt ook containers die niet reageren op door de gebruiker gedefinieerde statuschecks en adverteert ze pas bij klanten als ze klaar zijn om te serveren.
  • Geautomatiseerde roll-outs en rollback: Kubernetes implementeert wijzigingen in de app of de configuratie ervan terwijl de status van de app wordt gecontroleerd om ervoor te zorgen dat niet al uw instanties tegelijkertijd worden afgesloten. Als er iets misgaat, kunt u met Kubernetes de wijziging ongedaan maken.
  • Horizontaal schalen en load balancing: Kubernetes kan de applicatie opschalen en verkleinen volgens de vereisten met een eenvoudige opdracht, met behulp van een gebruikersinterface of automatisch op basis van CPU-gebruik.

Kubernetes-zelfstudie: Kubernetes-architectuur

Kubernetes Architecture heeft de volgende hoofdcomponenten:

  • Hoofdknooppunten
  • Worker / Slave-knooppunten

Ik ga ze allemaal een voor een bespreken. Laten we eerst beginnen met het begrijpen van de Hoofdknooppunt .

Hoofdknooppunt

De master node is verantwoordelijk voor het beheer van het Kubernetes-cluster. Het is vooral het toegangspunt voor alle administratieve taken. Er kan meer dan één masterknooppunt in het cluster zijn om te controleren op fouttolerantie.

Zoals je in het bovenstaande diagram kunt zien, heeft het masterknooppunt verschillende componenten zoals API Server, Controller Manager, Scheduler en ETCD.

  • API-server: De API-server is het toegangspunt voor alle REST-opdrachten die worden gebruikt om het cluster te besturen.
  • Controller Manager: Is een daemon die het Kubernetes-cluster reguleert en verschillende niet-afsluitende controlelussen beheert.
  • Planner: De planner plant de taken naar slaafknooppunten. Het slaat de informatie over het gebruik van bronnen op voor elk slaafknooppunt.
  • ETCD: ETCD is een eenvoudige, gedistribueerde, consistente sleutelwaardeopslag. Het wordt voornamelijk gebruikt voor gedeelde configuratie en service-detectie.

Worker / Slave-knooppunten

Werkknooppunten bevatten alle noodzakelijke services om het netwerk tussen de containers te beheren, te communiceren met het hoofdknooppunt en bronnen toe te wijzen aan de geplande containers.

Zoals u in het bovenstaande diagram kunt zien, heeft het werkknooppunt verschillende componenten, zoals Docker Container, Kubelet, Kube-proxy en Pods.

  • Docker-container: Docker wordt op elk van de werkknooppunten uitgevoerd en voert de geconfigureerde pods uit
  • Kubelet: Kubelet haalt de configuratie van een Pod op van de API-server en zorgt ervoor dat de beschreven containers up and running zijn.
  • Cuba proxy: Kube-proxy fungeert als een netwerkproxy en een load balancer voor een service op één werkknooppunt
  • Peulen: Een pod is een of meer containers die logisch samen op knooppunten worden uitgevoerd.

Wilt u een uitgebreide uitleg van alle onderdelen van Kubernetes Architecture, dan kunt u terecht bij ons blog op

Wilt u gecertificeerd worden in Kubernetes?

Kubernetes-zelfstudie: Kubernetes-casestudy

Y ahoo! JAPAN is een webserviceprovider met hoofdkantoor in Sunnyvale, Californië. Toen het bedrijf de hardware wilde virtualiseren, begon het bedrijf te gebruiken OpenStack in 2012. Hun interne omgeving veranderde erg snel. Vanwege de voortgang van cloud- en containertechnologie wilde het bedrijf echter de capade mogelijkheid om diensten op verschillende platforms te lanceren.

Probleem: Hoe maak je afbeeldingen voor alle vereiste platforms vanuit één applicatiecode en implementeer je die afbeeldingen op elk platform?

Raadpleeg de onderstaande afbeelding voor een beter begrip. Wanneer de code wordt gewijzigd in het coderegister, worden bare metal-images, Docker-containers en VM-images gemaakt door tools voor continue integratie, naar het image-register gepusht en vervolgens op elk infrastructuurplatform geïmplementeerd.


Laten we ons nu concentreren op de containerworkflow om te begrijpen hoe ze Kubernetes als implementatieplatform hebben gebruikt. Raadpleeg de onderstaande afbeelding om een ​​kijkje te nemen in de platformarchitectuur.

OpenStack-instanties worden gebruikt, met Docker, Kubernetes, Calico, enz. Erbovenop om verschillende bewerkingen uit te voeren, zoals Container Networking, Container Registry, enzovoort.

Als je meerdere clusters hebt, wordt het moeilijk om ze te beheren, toch?

samenvoegen sorteeralgoritme c ++

Dus wilden ze gewoon een eenvoudig, basis OpenStack-cluster maken om de basisfunctionaliteit te bieden die nodig is voor Kubernetes en om de OpenStack-omgeving gemakkelijker te beheren te maken.

Door de combinatie van de workflow voor het maken van afbeeldingen en Kubernetes, hebben ze de onderstaande toolchain gebouwd die het gemakkelijk maakt van codepush tot implementatie.


Dit soort toolchain zorgde ervoor dat alle factoren voor productie-implementatie, zoals multi-tenancy, authenticatie, opslag, netwerken, service discovery in aanmerking werden genomen.

Dat is hoe mensen, Yahoo! JAPAN bouwde een automatiseringstoolchain voor implementatie van code met één klik naar Kubernetes die op OpenStack draaien, met hulp van Google en Solinea .

Governors Tutorial: Hands-On

In deze Hands-On laat ik je zien hoe je een implementatie en een service maakt. Ik gebruik een Amazon EC2-instantie om Kubernetes te gebruiken. Nou, Amazon heeft het bedacht Amazon Elastic Container Service voor Gouverneurs (Amazon EKS) , waarmee ze heel snel en gemakkelijk Kubernetes-clusters in de cloud kunnen maken. Als je er meer over wilt weten, kun je de blog raadplegen

Stap 1: Eerste maak een map waarbinnen u uw implementatie en service creëert. Gebruik daarna een editor en open een implementatiebestand .

mkdir handsOn cd handsOn vi Deploy.yaml

Stap 2: Nadat u het implementatiebestand heeft geopend, vermeldt u alle specificaties van de applicatie die u wilt implementeren. Hier probeer ik een httpd toepassing.

apiVersion: apps / v1 # Definieert de API-versie type: Deployment #Kinds parameter definieert welk type bestand het is, hier is het Implementatie metadata: naam: dep1 # Slaat de naam op van de implementatie specificatie: # Onder Specificaties noemt u alles de specificaties voor de implementatiereplica's: 3 # Aantal replica's zou 3 zijn selector: matchLabels: app: httpd #Labelnaam die zou worden doorzocht is httpd template: metadata: labels: app: httpd #Template naam zou httpd spec: # Under Specificaties, u vermeldt alle specificaties voor de containers containers: - naam: httpd # Naam van de containers zou httpd afbeelding: httpd: laatste # De afbeelding die gedownload moet worden is httpd: laatste poorten: - containerPort: 80 # De applicatie zou worden blootgesteld op poort 80

Stap 3: Nadat u uw implementatiebestand heeft geschreven, past u de implementatie toe met behulp van de volgende opdracht.

kubectl apply -f Deploy.yaml

Hier -f is een vlagnaam die wordt gebruikt voorthij bestandnaam.

Stap 4: Nu, zodra de implementatie is toegepast, laat u de lijst met pods draaien.

kubectl krijgt pods -o breed

Hier wordt -o breed gebruikt om te weten op welk knooppunt de implementatie wordt uitgevoerd.

Stap 5: Nadat u een implementatie heeft gemaakt, moet u nu een service maken. Gebruik daarvoor opnieuw een editor en open een blanco onderhoud. yaml-bestand .

vi service.yaml

Stap 6: Zodra u een servicebestand opent, vermeldt u alle specificaties voor de service.

apiVersion: v1 #Definieert de API-versie kind: Service #Kinds parameter definieert welk type bestand het is, hier is het Service metadata: naam: netsvc # Slaat de naam van de servicespecificatie op: # Onder Specificaties noemt u alle specificaties voor het servicetype: NodePort-selector: app: httpd poorten: -protocol: TCP-poort: 80 targetPort: 8084 #Target Poortnummer is 8084

Stap 7: Nadat u uw servicebestand heeft geschreven, past u het servicebestand toe met de volgende opdracht.

kubectl pas -f service.yaml toe

Stap 8: Nu, zodra uw service is toegepast om te controleren of de service actief is of niet, gebruikt u de volgende opdracht.

kubectl krijgt svc

Stap 9: Nu om de specificaties van de service te zien en te controleren welk eindpunt het isgebonden aan, gebruikt u de volgende opdracht.

kubectl beschrijft svc

Stap 10: Nu we de Amazon ec2-instantie gebruiken, gebruik je de volgende opdracht om de webpagina op te halen en de uitvoer te controleren.

curl ip-adres

Als je deze Kubernetes Tutorial-blog relevant vond, bekijk dan het door Edureka, een vertrouwd online leerbedrijf met een netwerk van meer dan 250.000 tevreden leerlingen verspreid over de hele wereld.

Heeft u een vraag voor ons? Vermeld het in het opmerkingengedeelte van ' Kubernetes-zelfstudie ”En ik neem contact met je op.