‫Kubernetes of Zwerm.
‫Het is een van de meest populaire vragen die ik krijg nadat iemand
‫genoeg over orkestratie heeft geleerd om vervolgens een beslissing te willen nemen
‫over welke te gebruiken.
‫Ik zou je aanraden om eerst de video's
‫op Swarm te bekijken, vooral de
‫allereerste video daarvan. Dat
‫is de ingebouwde orkestratie in de zwermmodus, want nogmaals,
‫dat geeft je de achtergrond waarom orkestratie nodig is om
‫bepaalde problemen op te lossen. Bekijk dan ook de video's
‫die eerder in dit onderdeel over Kubernetes zijn geplaatst, zodat
‫je de achtergrond van beide tools begrijpt voordat we
‫verder gaan. Als basislijn zijn dit
‫beide tools die vergelijkbare problemen oplossen. Het zijn beide container-orchestrators
‫die bovenop een
‫containerruntime worden uitgevoerd.
‫In deze videoserie heb je geleerd over
‫de Docker-containerruntime.
‫Er zijn er nu andere, containers en CRI-O.
‫Echt, Docker is de #1.
‫Het wordt in bijna alle gevallen gebruikt.
‫Beide worden ondersteund door leveranciers en teams van mensen
‫die aan de producten werken.
‫In het algemeen, als ik een tweet zou moeten
‫maken om de twee te vergelijken, zou het eenvoudig zijn dat Swarm eenvoudig uit te bouwen is,
‫gemakkelijk knooppunten toe te voegen, gemakkelijk aan de slag te
‫gaan en gemakkelijk te beheren. Dus gemakkelijk is absoluut
‫het one-liner-ding dat ik zou zeggen voor Swarm.
‫Maar het lost niet alle gevallen
‫op waarin Kubernetes veel meer functionaliteit, flexibiliteit
‫en maatwerk heeft. Het kan meer problemen oplossen, op
‫meer manieren, en heeft over het algemeen ook een bredere
‫acceptatie en ondersteuning.
‫Om u te helpen beslissen welke u wilt
‫gebruiken, gaan we enkele opsommingen van voordelen
‫van elk doornemen. Ik denk dat het echt belangrijk
‫is voor ons allemaal als je deel gaat uitmaken van de DevOps-gemeenschap en
‫deze tools gebruikt om zakelijke problemen op te lossen, dat
‫je beide moet weten.
‫Je zou in staat moeten zijn om beide te installeren
‫en vervolgens apps op beide te implementeren, en
‫een deel van de basisfunctionaliteit te kennen rond het implementeren van apps, het
‫creëren van Ingress-opties voor binnenkomend verkeer en het vervolgens
‫bijwerken van die apps. Ik denk dat
‫je daardoor alleen al genoeg vertrouwd raakt met de tools, zodat je
‫weet welke je moet gebruiken om welke problemen op te lossen.
‫Er zijn veel voordelen voor elk.
‫Laten we dit heel snel opsplitsen. Aan de kant
‫van de zwerm, zoals je tijdens deze cursus hebt geleerd,
‫wordt het geleverd met Docker. Het is dus een enkele, door de leverancier ondersteunde oplossing.
‫Dat betekent dat de containerruntime en de orchestrator
‫door hetzelfde bedrijf zijn gebouwd.
‫Dat plukt veel voordelen, waaronder minder complexiteit, minder gebruik van bronnen
‫alleen voor het runnen van
‫het ding. Running Swarm heeft
‫zeer weinig gebruik van hulpbronnen bovenop Docker.
‫Het is ontworpen met de workflow van de
‫ontwikkelaar in gedachten. Het is dus heel
‫goed voor Ops en ontwikkelaars om te gebruiken. Zoals ik al zei, het is
‫gemakkelijk om een orkestrator van dit type te implementeren en te beheren.
‫Het kan gemakkelijk uitgroeien tot vele honderden, zo niet duizenden
‫knooppunten, en je hebt niet per se een groot
‫team nodig om het te beheren. Je
‫zou kunnen zeggen dat het de 80/20-regel volgt, waar het 20%
‫van de functies van Kubernetes heeft, en dat 80% van de
‫use-cases voor het uitvoeren van containers
‫en orkestratie oplost.
‫Dat is geen wetenschappelijke vergelijking.
‫Ik weet het exacte featurenummer niet echt. Ik weet niet
‫hoe je dat echt zou doen.
‫Maar dat lijkt het gevoel te zijn wanneer je beide uitvoert, dat
‫je je realiseert dat Swarm een meerderheid van de
‫use-cases oplost voor het uitvoeren van langlopende web-apps oplossingen op servers,
‫of het nu in de cloud of datacenter is, of zelfs
‫op kleine apparaten. Het lijkt out-of-the-box goed
‫te werken. Het heeft wat je nodig hebt. Het
‫heeft het netwerk. Het heeft de Ingress. Het heeft de codering.
‫Al dat soort dingen. Het heeft de database.
‫Dus, out-of-the-box, lost het echt veel problemen op.
‫Maar het lost niet alle use-cases op, voor alle scenario's, om een app op een machine
‫uit te voeren.
‫Dat is waar Kubernetes het gat kan vullen.
‫Een ander groot voordeel hiervan is dat het overal
‫draait waar Docker draait. Docker Engine, nu zes
‫jaar oud en het begin van deze hele containerrevolutie,
‫draait op meer plaatsen dan enig ander gereedschap.
‫Het draait niet alleen op Linux, het draait op Windows.
‫Het draait op Mainframe.
‫Het draait op ARM-apparaten, wat betekent
‫Embedded, IoT, Raspberry Pis.
‫Het draait op oude ARM, nieuwe ARM, 32
‫bit, 64 bit. Zoals ik al zei, het is gewoon overal.
‫Het draait al jaren native op Windows
‫Server sinds Server 2016.
‫Het is dus absoluut de langst ondersteunde orchestrator voor
‫een diverse omgeving met meerdere architectuur, als dat uw
‫behoeften zijn.
‫Out-of-the-box, het is veilig, en je
‫hebt me daar in deze cursus over
‫horen praten, dat wanneer je een zwerm maakt en knooppunten toevoegt,
‫het zorgt voor wederzijdse Telus-authenticatie. Het versleutelt het besturingsvlak en het versleutelt
‫de database om uw geheimen te beschermen voor het
‫geval u die wilt opslaan.
‫Dat is geweldig, want ik merk dat veel teams, wanneer ze
‫haast hebben met deadlines of
‫misschien een beetje overweldigd zijn door de complexiteit,
‫de neiging hebben om enkele van de beveiligingsvereisten te vergeten of over te slaan
‫die andere tools zoals Kubernetes vereisen. Ten slotte geloof ik dat het
‫gemakkelijker is om problemen op te lossen omdat er minder bewegende
‫delen bij zijn. Er zijn minder dingen te regelen.
‫Omdat het standaard in Docker is ingebouwd, weet je waarschijnlijk hoe
‫je problemen met Swarm kunt oplossen als je weet hoe
‫je Docker moet oplossen.
‫Het gebruikt dezelfde daemon-logboeken. Het gebruikt dezelfde
‫Docker logs-opdracht voor de apps. Het gebruikt hetzelfde Docker-evenementen-commando om
‫naar gebeurtenissen op de knooppunten en de zwerm zelf te
‫kijken. Dat klinkt als
‫veel voordelen voor een zwerm, maar ik wil niet dat je denkt
‫dat dat altijd het juiste voor je zal
‫zijn.
‫Over het algemeen is Swarm de tool die ik aanbeveel
‫wanneer mensen beginnen en ze klein beginnen.
‫Misschien zijn ze een enkele persoon, of slechts een,
‫twee of drie mensen in hun team, en moeten ze
‫zien of een kleine, eenvoudige orkestrator voor
‫hen gaat werken. Ik raad altijd eerst Swarm
‫aan, tenzij je absoluut weet dat je Kubernetes moet gebruiken,
‫raad ik Swarm aan. Als je eenmaal denkt dat je een
‫aantal limieten hebt bereikt in Swarm en je denkt dat je er niet helemaal uit kunt
‫halen wat je nodig hebt, dan is het tijd
‫om naar Kubernetes te kijken.
‫Laten we het nu hebben over enkele van die voordelen.
‫Ten eerste, dat clouds en leveranciers Kubernetes heel
‫graag ondersteunen. Omdat het zo populair is
‫geworden, en vooral een soort tijdgeest-achtige populariteit in het nieuws
‫en de media, is het iets dat
‫elke leverancier nu wil afvinken op hun lijst met
‫ondersteuning van Kubernetes.
‫Dus ik zou zeggen dat het absoluut de breedste cloud-
‫en leveranciersondersteuning heeft.
‫Elke cloudleverancier biedt wel een aanbod van Kubernetes, dus als
‫u het niet zelf wilt uitvoeren, kunt u ze
‫gewoon alle systemen laten opstarten en dan
‫draait u in wezen gewoon uw apps daar met
‫behulp van Kubernetes-implementatiebestanden. Zelfs leveranciers van
‫infrastructuur hebben nu hun eigen Kubernetes-distributie, waaronder VMware,
‫Red Hat. Zelfs bedrijven zoals
‫Netflix, die traditioneel slechts een opslagverkoper zijn, hebben hun
‫eigen goedgekeurde versie of distributie van Kubernetes.
‫Dus het voor de hand liggende lijkt hier te zijn dat
‫het de breedste acceptatie en ondersteuning heeft, en dat is absoluut waar.
‫Maar daarnaast heeft het ook de breedste reeks ondersteunde
‫gebruiksscenario's. Omdat
‫het zoveel meer dingen heeft om mee te schakelen
‫en te spelen, en zoveel verschillende
‫functies en opties van derden, dekt het zeker meer
‫van de randgevallen dan Swarm. In feite zul je dit gaan
‫zien bij leveranciers waarmee je waarschijnlijk al werkt vandaag,
‫waar ze Kubernetes eerste ondersteuning zullen bieden, wat
‫mijn manier is om te zeggen dat leveranciers zullen kijken hoe ze
‫Kubernetes kunnen ondersteunen met hun product voordat ze de moeite nemen om naar Docker's
‫Swarm-product te gaan kijken.
‫Vooral omdat de industrie zo'n beetje in deze houding zit
‫dat alles nodig is om
‫Kubernetes te ondersteunen, je zult merken dat leveranciers die je al
‫hebt misschien al een distributie of een oplossing hebben om hun
‫tools op Kubernetes te laten draaien. Bijvoorbeeld met Jenkins, van
‫het bedrijf CloudBees.
‫Als u hun Enterprise-oplossing hebt gekocht, geven ze
‫u Kubernetes-tooling en voorbeelden over hoe u deze moet uitvoeren.
‫Het betekent niet dat je Jenkins niet op Swarm kunt draaien.
‫Het loopt daar geweldig.
‫Het betekent alleen dat u daarvoor betere ondersteuning krijgt
‫van de leverancier.
‫Het laatste voordeel dat ik hier zal noemen, is
‫een soort raar voordeel. Ik ga overgeven met deze term
‫dat niemand ooit is ontslagen voor het kopen van IBM.
‫Dit gezegde was tientallen jaren geleden populair toen IBM
‫de grootste leverancier was voor het computeren en uitbesteden van
‫uw hardware, en uw mainframes en uw pc's, en er was
‫een hele tijd dat ze het echt op de
‫markt aan het doden waren.
‫In wezen, als u geen beslissing kon nemen over met welke
‫leverancier u in zee wilde gaan. Als je gewoon de
‫veilige weg zou gaan, zou je met IBM gaan.
‫Daar zou je nooit echt voor ontslagen worden omdat het de
‫vertrouwde verkoper van die tijd was.
‫Ik zou zeggen dat dat nu in het algemeen voor
‫het Kubernetes-platform als geheel het geval is geworden.
‫Ik zou zelfs willen beweren dat het zelfs zo ver is gekomen
‫dat het een afvinkitem is voor CIO's en CTO's.
‫Dat kan een beetje goed en slecht zijn, want dat
‫kan betekenen dat je wordt verteld om Kubernetes te gebruiken, ook
‫al heb je nog geen technische vereisten.
‫Uw management heeft u zojuist verteld dat we
‫Kubernetes moeten runnen. Dat is voor
‫hen misschien iets dat ze willen uitvoeren, ongeacht de technische
‫vereisten of voordelen, of het vergelijken met verschillende platforms.
‫Dat maakt duidelijk deel uit van deze politieke
‫wereld waar IT-beslissingen niet altijd alleen op technische merites
‫of vereisten worden genomen.
‫Het kan vaak zijn door het gebruiksgemak
‫van het kopen. Met andere woorden, als u
‫al een leverancier heeft die er een heeft, kunt u gewoon hun product gebruiken in plaats
‫van een ander product, omdat dat gemakkelijker is.
‫Of uw teamervaring op de achtergrond heeft mogelijk betere
‫ervaring met hun eerdere banen of projecten.
‫Dus je gaat die gewoon inzetten omdat iemand
‫het al weet. Of misschien ga je het kopen omdat
‫je management helaas een tijdschrift heeft gelezen, of internet heeft gelezen,
‫en het internet vertelde hen dat ze een bepaald product
‫zoals Kubernetes moesten kiezen.
‫Dus dat is degene die ze je vertellen te gebruiken.
‫Als ik live workshops geef en mensen vraag waarom ze de
‫orkestrator hebben gekozen die ze leiden, is het meest voorkomende
‫antwoord dat ik helaas van hen krijg, helaas nog steeds: mijn baas zei
‫dat ik dit moest doen.
‫Mensen hebben dus niet altijd inspraak in wat ze doen, daarom
‫probeer ik je een goede balans te geven tussen de tools
‫en functies van beide, zodat je de best opgeleide persoon in je team
‫wordt en in staat om hen te helpen
‫met de echte technische vereisten en u te helpen de beste beslissing te nemen.