‫Laten we het hebben over waarom u Kubernetes nodig heeft.
‫Kijk nu als een recensie terug
‫met de eerdere secties. Het eerste gedeelte voor Swarm
‫en er is een lezing getiteld Swarm Mode Built-in Orchestration.
‫Dat geeft je een aantal basisprincipes over de
‫problemen die orkestratie oplost en waarom je het
‫misschien nodig hebt. Ik zal benadrukken dat
‫het in het begin absoluut belangrijk is
‫dat je begrijpt welke orkestratievoordelen je nodig hebt om je
‫applicaties te implementeren, en of je om te
‫beginnen al dan niet orkestratie nodig hebt.
‫Orkestratie wordt zeker steeds populairder, maar het is niet de
‫enige manier om containers uit te voeren.
‫We hebben het hier gehad over het gebruik van Docker-runs.
‫We hebben het gehad over Docker Compose.
‫We hebben het gehad over andere platformaanbiedingen en -diensten.
‫Ik heb klanten die nog
‫steeds containers op enkele knooppunten in AWS draaien
‫zonder orkestratie. Ze gebruiken de
‫functies van dat platform om een soortgelijk abstractie als orkestratie te
‫creëren, waarbij ze misschien groepen voor automatisch schalen, Elastic Load Balancing
‫en een heleboel andere dingen gebruiken die we allemaal
‫al meer dan tien jaar gebruiken om
‫onze applicatie-implementaties te beheren.
‫Ze hebben zo'n verfijnd systeem dat ze gewoon niet
‫veel voordelen zien om dat allemaal volledig te
‫veranderen in orkestratie.
‫Nu zullen de meesten van ons uiteindelijk een
‫of andere vorm van containerorkestratie gebruiken, want dat is echt de manier
‫waarop ik denk dat de industrie gaat, en dit zullen allemaal
‫deze extra lagen zijn die bovenop Docker draaien, of een
‫andere runtime, en dat is wat je heb geleerd
‫tijdens deze cursus.
‫Een van de eenvoudige formules die ik gebruik om
‫al dan niet orkestratie
‫te gebruiken, is het aantal servers nemen
‫dat ik nodig heb voor een bepaalde omgeving, en
‫dan de veranderingssnelheid van mijn applicaties, of de omgeving
‫zelf, en de vermenigvuldiging van die twee zijn echt gelijk
‫aan het voordeel van orkestratie.
‫Wat ik daarmee bedoel, is dat orkestratie is ontworpen om verandering te
‫automatiseren en de stand van zaken
‫te bewaken en ervoor te zorgen dat alles de staat is
‫die u verwacht.
‫Bijvoorbeeld apps die in een gezonde staat worden uitgevoerd.
‫Als je begint, heb je misschien maar
‫één server nodig, of slechts een paar servers, en
‫als je je applicaties niet vaak verandert, laten we zeggen dat
‫je ze slechts één keer per maand of minder verandert, dan orkestratie,
‫en de inspanning die nodig is om het in te zetten,
‫te beheren en te beveiligen, kan in uw
‫land niet nodig zijn. Vooral als je een solo-ontwikkelaar
‫bent of slechts een heel klein team.
‫Dat is waar dingen als Elastic Beanstalk, of Heroku,
‫het applicatie-implementatieplatform, dat is waar veel van die
‫dingen beginnen te schitteren als alternatieven voor het
‫doen van je eigen orkestratie.
‫Natuurlijk is de meest voorkomende vraag die
‫ik krijg van mensen als ze eenmaal door hebben
‫dat ze orkestratie nodig hebben, te beslissen welke ze willen.
‫Echt, op dit punt in
‫2019 zijn er minstens twee of drie grote platforms.
‫Als je de Cloud-oplossingen meetelt, zijn daar misschien vier
‫of vijf grote platforms.
‫Degene waar ik het in deze cursus over heb, zijn de
‫top twee die overal werken. Dat zijn Swarm en Kubernetes.
‫Dan heb je andere die specifiek
‫zijn voor Cloud-platforms, zoals
‫ECS, dat alleen op AWS is, en meer
‫traditionele aanbiedingen die al wat langer
‫bestaan, zoals Cloud Foundry, of Mesos en Marathon.
‫Maar ik denk dat als je iemand
‫bent die zich zorgen maakt over het draaien van containers
‫op locatie en in de cloud, of mogelijk multicloud, je
‫misschien niet wilt gaan met die cloud-specifieke aanbiedingen zoals
‫ECS, omdat die er al waren voordat Kubernetes was.
‫Dus dat was een soort legacy-oplossing die Amazon nog steeds ondersteunt en
‫het is nog steeds een leuke optie, maar alleen als je specifiek bent voor
‫AWS en dat is de enige plaats waar je ooit van plan
‫bent containers in te zetten.
‫Voor veel van mijn klanten, en voor veel van mijn
‫studenten, zijn de keuzes meestal: ik heb iets nodig dat hybride is.
‫Dit betekent dat ik het in mijn datacenter
‫of in multicloud kan draaien. Het kan niet
‫alleen op één locatie draaien. Dat komt neer op meestal
‫Swarm of Kubernetes als hun grote keuzes, want dat
‫zijn twee oplossingen die de meest populaire
‫container-orkestrators zijn.
‫Ze draaien op elke cloud, en in datacenters, en zelfs
‫in kleine omgevingen, mogelijk zoals IoT.
‫Als u Kubernetes als uw orkestrator
‫kiest, is de volgende grote beslissing welke distributie
‫u gaat gebruiken.
‫Het eerste deel daarvan is om erachter te komen of u
‫een door de cloud beheerde oplossing wilt,
‫of dat u uw eigen oplossing wilt implementeren met een product van
‫een leverancier dat u zelf op de servers zou installeren.
‫Veelvoorkomende distributies die door leveranciers worden ondersteund en waarover
‫je me hebt horen praten, inclusief Docker Enterprise
‫en er zijn andere zoals Rancher OpenShift
‫van Red Hat. Canonical, het bedrijf Ubuntu, heeft
‫hun eigen versie.
‫VMware heeft hun eigen versie.
‫PKS ook.
‫In feite zijn er zoveel leveranciersoplossingen
‫voor infrastructuur en softwarebedrijven voor Kubernetes nu het
‫een beetje overweldigend is.
‫Ik geef je een link in de bronnen naar een lijst
‫met de door Kubernetes gecertificeerde distributies.
‫U wilt een van deze gebruiken omdat ze garanderen
‫dat de API van Kubernetes direct wordt gebruikt en dat deze
‫volledig wordt ondersteund.
‫Het ideale geval is dus dat u uw workloads en
‫uw YAML-bestanden die uw infrastructuur ontwerpen, kunt gebruiken, en u kunt
‫die van de ene Kubernetes-leverancier naar de
‫andere verplaatsen en ze zouden voor de meeste dingen
‫out-of-the-box moeten werken.
‫Nu is er nog een andere optie die ik
‫hier zojuist heb genoemd, namelijk het gebruik van de onbewerkte
‫GitHub-upstreamversie van Kubernetes.
‫Daar zijn alle distributies op gebaseerd.
‫Als je bijvoorbeeld stroomopwaarts kijkt en je ziet
‫Kubernetes 1. 14 vrijgeven.
‫Als u vervolgens naar een product van
‫een leverancier kijkt, zou u geïnteresseerd zijn in welke Kubernetes-versies ze ondersteunen.
‫Meestal lopen leveranciersproducten een paar versies achter, maar tegenwoordig is
‫de race dat ze allemaal zo
‫veel mogelijk up-to-date blijven.
‫Dus ik heb de neiging om ze meestal maar één versie te zien
‫die verouderd is.
‫Wat je nu krijgt van
‫leveranciersoplossingen, naast alleen de ondersteuningsopties van die leverancier,
‫is ook het bundelen van andere tools.
‫Een van de dingen aan Kubernetes die
‫een beetje anders is dan Swarm, is dat
‫er veel dingen aan moeten worden toegevoegd om het echt
‫gebruiksvriendelijk te maken. Dus u zult
‫waarschijnlijk, wanneer u een oplossing van een leverancier aanschaft,
‫dingen zien als aangepaste authenticatie-oplossingen, aangepast webbeheer en aangepaste netwerken, om
‫er maar een paar te noemen.
‫Ik zal u over het algemeen aanbevelen,
‫zonder uw vereisten te kennen, dat
‫u waarschijnlijk de pure upstream-versie van GitHub's
‫Kubernetes niet nodig hebt.
‫U hoeft de repo van Kubernetes niet te klonen en alleen dat
‫uit te voeren.
‫Nu is het geweldig om te leren.
‫Ik raad zelfs aan om daarmee te beginnen als de manier
‫om Kubernetes te leren. Maar als je eenmaal in
‫de oplossingen van leveranciers bent beland, zullen die allemaal
‫een beetje anders zijn met beveiliging, en netwerken en andere dingen.
‫Dus het zal moeilijk voor je zijn om er een te leren en dan
‫gewoon aan te nemen dat de andere op dezelfde manier handelt.
‫Als je het echter over productie hebt, zou ik
‫verwachten dat je eerst een van die
‫oplossingen van leveranciers zou proberen te gebruiken, omdat ze gemakkelijker
‫te beheren zijn. Je krijgt betere ondersteuningsopties.
‫Over het algemeen zullen dingen out-of-the-box gewoon beter en sneller werken.