School of Innovation Design and Engineering
V¨
aster˚
as, Sweden
Examensarbete f¨
or h¨
ogskoleingenj¨
orsexamen i n¨
atverksteknik
DVA333 - 15hp
ORKESTRERING I DOCKER
-J ¨
AMF ¨
ORELSE MELLAN DOCKER
SWARM OCH KUBERNETES
Pontus Dagerfall
pdl16002@student.mdh.se
Vilhelm Beijer
vbr16001@student.mdh.se
Examinator: Moris Behnam
M¨
alardalen University, V¨
aster˚
as, Sweden
Handledare: Mohammad Ashjaei
M¨
alardalen University, V¨
aster˚
as, Sweden
Mats Bj¨
orkman
M¨
alardalen University, V¨
aster˚
as, Sweden
Sammanfattning
I en v¨arld d¨ar ny teknik introduceras hela tiden kan det ibland vara sv˚art att v¨alja vilka verktyg man ska anv¨anda. F¨or att l¨osa en uppgift kan det finnas en uppsj¨o av olika program, applikationer och redskap tillg¨angliga, men hur vet man vilken som ¨ar b¨ast l¨ampad f¨or den uppgiften man ska utf¨ora? I den h¨ar rapporten ¨ar meningen att vi ska svara p˚a den fr˚agan n¨ar det specifikt hand-lar om orkerstreringsverktyg f¨or Docker. Docker ¨ar en virtualiseringsmetod som till skillnad fr˚an traditionella virtuella maskiner isolerar processer snarare ¨an hela operativsystem, vilket i sin tur g¨or det mer modul¨art och smidigt att arbeta med. Vill man dessutom anv¨anda denna teknik i en distribuerad milj¨o ¨ar det nyttigt att veta vilka verktyg som har vilka styrkor. F¨or att under¨oka detta har vi j¨amf¨ort de tv˚a popul¨araste orkerstreringsverktygen f¨or Docker; Docker Swarm och Kuber-netes. Vi har j¨amf¨ort dessa tv˚a verktyg dels genom en litteraturstudie d¨ar vi presenterar kvalitativ data f¨or anv¨andarv¨anlighet och dokumentation, och en m¨angd kvantitativa tester d¨ar vi m¨ater pre-standa i redundans, migrering och applikationsskalning. Med dessa tester ¨amnar vi underl¨atta f¨or administrat¨orer och lekm¨an som s¨oker den b¨asta l¨osningen f¨or sin distribuerade Docker-milj¨o. Re-sultatet av literaturstudien och de kvantitativa testerna g˚ar i s¨ar vad g¨aller m¨ojligheten att ta fram ett fullst¨andigt svar f¨or alla situationer. Docker Swarm placerar sig l˚angt ¨over Kubernetes i fr˚aga om anv¨andarv¨anlighet medan Kubernetes levererar l˚angt b¨attre effektivitet och funktionalitet. Detta menar vi betyder att Docker Swarm ¨ar det b¨attre verktyget f¨or mindre milj¨oer d¨ar l¨atthanterlig ad-ministrering v¨arderas h¨ogt medans Kubernetes ¨ar det b¨attre alternativet f¨or st¨orre infrastrukturer med h¨ogre krav f¨or funktionalitet och l˚ag latens.
Inneh˚
all
1. Inledning 1
1.1 Problemformulering . . . 1
1.2 Oversikt . . . .¨ 1
2. Bakgrund 2 2.1 Hur fungerar virtualisering? . . . 2
2.2 Hypervisor-baserad virtualisering . . . 2 2.3 Container-baserad virtualisering . . . 3 2.4 Docker . . . 3 2.4.1 Docker engine . . . 4 2.4.2 Docker images . . . 4 2.5 Orkestrering i Docker . . . 5 2.5.1 Docker Swarm . . . 5 2.5.2 Kubernetes . . . 5 2.5.3 Arkitekturen i Kubernetes . . . 6
2.5.4 Kluster-n¨atverk i Kubernetes . . . 6
2.6 Node.js . . . 7
2.7 HTTP-funktioner . . . 7
2.8 Amazon Web Services . . . 7
3. Relaterade arbeten 8 4. Metod 10 4.1 Analytisk unders¨okning . . . 10
4.2 Experiment . . . 10
5. J¨amf¨orelse av orkestreringsverktyg 12 5.1 Amazon Web Services . . . 12
5.2 F¨orberedande installationer . . . 12
5.2.1 Installation av Docker och Docker Swarm . . . 12
5.2.2 Installation av Docker och Kubernetes . . . 13
5.2.3 Node.js . . . 13
5.2.4 Drifts¨attning av Docker Swarm . . . 13
5.2.5 Drifts¨attning av Kubernetes . . . 14
5.3 Tester . . . 14
5.3.1 Tester i Docker Swarm . . . 15
5.3.2 Tester i Kubernetes . . . 17 6. Resultat 18 6.1 Applikationsskalning . . . 18 6.2 Migrering . . . 20 6.3 Redundans . . . 22 7. Diskussion 24 7.1 Begr¨ansningar som kan p˚averkat resultatet . . . 25
8. Slutsatser 26 8.1 Framtida arbeten och f¨orb¨attringar . . . 26
Referenser 28
Bilaga A Installation av Docker Swarm 29
Bilaga B Installation av Kubernetes 30
Bilaga C Node.js applikation 31
Bilaga D Dockerfile 32
Bilaga E Package.json fil 33
Bilaga F YAML-fil f¨or service och deployment 34 Bilaga G Script f¨or migreringstester i Docker Swarm 35 Bilaga H Patchfiler f¨or migreringstester i Kubernetes 36
Figurer
1 Uppbyggnaden av traditionellt VM. . . 2
2 Uppbyggnaden av containrar. . . 3
3 Docker engine. . . 4
4 Exempel p˚a en enkel Dockerfile. . . 5
5 Skillnader mellan Docker Swarm och Kubernetes [17]. . . 8
6 IP-adresser p˚a noder f¨or respektive orkestreringsverktyg. . . 12
7 Lista ¨over aktiva noder. . . 12
8 Lista ¨over aktiva noder. . . 13
9 Lista ¨over tj¨anster distribuering i Docker Swarm. . . 14
10 Lista ¨over tj¨anster och distribuering i Kubernetes. . . 14
11 Uppskalning i Docker Swarm. . . 15
12 Nedskalning i Docker Swarm. . . 15
13 Migrering fr˚an worker1 till worker2 i Docker Swarm. . . 16
14 Migrering fr˚an worker2 till worker1 i Docker Swarm. . . 16
15 Upp- och nedskalning i Kubernetes. . . 17
16 Migrering i Kubernetes. . . 17
17 Skalning fr˚an en nod till tv˚a i Docker Swarm (sekunder). . . 18
18 Skalning fr˚an en nod till tv˚a i Kubernetes (millisekunder). . . 18
19 Skalning fr˚an tv˚a noder till en nod i Kubernetes & Docker Swarm (millisekunder). 19 20 Migrering av tj¨anst i Docker Swarm (sekunder). . . 20
21 Migrering av tj¨anst i Docker Swarm (sekunder). . . 20
22 Migrering av tj¨anst i Kubernetes (millisekunder). . . 21
23 Migrering av tj¨anst i Kubernetes (millisekunder). . . 21
24 Redundans i Docker Swarm (millisekunder). . . 22
25 Redundans i Kubernetes (millisekunder). . . 22
26 Tappade paket i Kubernetes & Docker Swarm (stycken). . . 23 27 Gemensam graf f¨or redundanstid i Docker Swarm och Kubernetes (millisekunder). 23
1.
Inledning
Under de senaste ˚aren har det skett en stor utveckling kring omr˚adet virtualisering. Tekniken har existerat i m˚anga ˚ar men l¨ange f¨orh˚allit sig till den traditionella metoden hypervisor-baserad viru-talisering, som oftast ben¨amns som en virtuell maskin (VM). Det senaste ˚artiondet har container-baserad virtualisering vuxit allt mer och d¨ar Docker som plattform har f˚att stor uppm¨arksamhet p˚a marknaden. Den stora skillnaden ¨ar att virtualiseringen nu ist¨allet g¨ors p˚a operativsystemsniv˚a ist¨allet f¨or p˚a h˚ardvaruniv˚a. Docker anv¨ands i synnerhet f¨or att kunna separera applikationer fr˚an varandra genom att placera dessa i s˚a kallade containrar, processerna delar samma operativsystem men ¨ar isolerade fr˚an varandra.
Anv¨ander man Docker och samtidigt vill f˚a flera applikationer att samarbeta med varandra s˚a finns det l¨osningar f¨or det. Docker Swarm och Kubernetes ¨ar tv˚a orkestreringsverktyg som b˚ada anv¨ands f¨or hantering och distribuering av applikationer som befinner sig i containrar utspritt i en Docker-milj¨o. Valet av verktyg kan vara sv˚art d˚a det finns f¨ordelar och nackdelar med de b˚ada verktygen.
1.1
Problemformulering
Inom IT har kravet p˚a l˚ag latens snabbt tagit ¨over som viktigast fr˚aga och f¨or tr˚adl¨os kommu-nikation kommer 5G inneb¨ara b˚ade l˚ag latens och h¨og leveransgaranti. Det ¨ar dock inte bara kommunikationen som ska g˚a snabbt, tj¨ansterna som klienterna kommunicerar med m˚aste ocks˚a ha h¨og redundans och fels¨akerhet f¨or att alltid vara tillg¨angliga. I denna f¨orh˚allandevis nya v¨arld av l˚aglatenskrav har en ny virtualseringsmetod dykt upp; containrar. Containrar g¨or att man snabbt kan starta om och orkestrera m˚anga redundanta servrar enkelt, smidigt och s¨akert. Med dessa p˚ast˚aenden och tv˚a av de vanligaste orkestreringsverktygen f¨or containrar ¨amnar vi att f¨ors¨oka best¨amma vilket av dessa som ter sig b¨ast f¨or denna nya l˚aglatensv¨arld. De fr˚agest¨allningar som vi skall fokusera ytterligare p˚a ¨ar:
1. Hur skiljer sig orkestreringsverktyg Docker Swarm och Kubernetes ˚at n¨ar det kommer till prestanda, specifikt redundans, migrering och applikationsskalning?
2. Hur ter sig anv¨andarv¨anligheten och dokumentationen kring de b˚ada verktygen under installations-och test-f¨orloppet?
Docker Swarm och Kubernetes ¨ar tv˚a orkestreringsvertyg som b˚ada ¨ar och kommer vara till stor nytta i framtidens anv¨andning av container-baserad virtualisering. Det tekniska bidraget fr˚an det h¨ar arbetet kommer ut¨oka f¨orst˚aelsen om hur respektive verktyg beter sig prestandam¨assigt i de m¨atpunkter som vi tagit fram och testat, vilket i sin tur kommer underl¨atta valet av verktyg f¨or administrat¨orer i framtiden.
1.2
Oversikt
¨
Detta arbetet kommer f¨orst presentera en genomg˚ang av virtualisering i allm¨anhet, containrar i synnerhet, Docker som plattform och de tv˚a orkestreringverktygen. I beskrivningen av den prak-tiska delen av arbetet kommer vi redovisa f¨orberedande installationer och hur vi utformade och utf¨orde v˚ara j¨amf¨orelsetester samt vad resultatet blev. Avslutningsvis diskuterar vi resultatet samt olika aspekter och tankar kring arbetet som gjorts f¨or att sedan komma fram till en slutsats som besvarar v˚ara fr˚agest¨allningar.
2.
Bakgrund
Docker som plattform skiljer sig b˚ade tekniskt och filosofiskt fr˚an traditionell virtualsering vilket ger upphov till m˚anga nya m¨ojligheter. F¨or att f¨orst˚a de tekniska bitarna i Docker och containrar beh¨ovs f¨orst en f¨orst˚aelse i hur virtualisering fungerar.
2.1
Hur fungerar virtualisering?
Virtualisering ¨ar en teknik som anv¨ands f¨or att skapa en virtuell representation av ett datorsystem som kan simuleras som en komplett virtuell maskin (VM) med hj¨alp av en programvara [1]. En virtuell maskin tillhandah˚aller samma funktioner som en fysisk maskin genom att den anv¨ander den fysiska maskinens resurser s˚a som processor, minne och lagringsutrymme [2]. Med virtuali-sering g˚ar det att anv¨anda en fysisk enhet och f˚a den att fungera som om det vore flera, vilket bidrar till en f¨orb¨attrad effektivitet och reducerade kostnader av fysiska resurser [3]. Ett kluster av n¨atverkstj¨anster som annars beh¨ovt ett flertal individuella servrar kan d˚a ist¨allet k¨oras p˚a samma h˚ardvara men delas upp i olika virtuella maskiner.
Anv¨andningsomr˚adet f¨or virtualisering ¨ar v¨aldigt bred d˚a det finns m˚anga olika tekniker som anv¨ands f¨or olika ¨andam˚al. Majoriteten av alla virtualiseringsteknikerna kan placera sig i n˚agon av de tv˚a huvudsakliga metoderna: Container-baserad virtualisering eller hypervisor-baserad vir-tualisering [4].
2.2
Hypervisor-baserad virtualisering
Hypervisor-baserad virtualisering, tillhandah˚aller virtualisering p˚a h˚ardvaruniv˚a som inneb¨ar att varje host anv¨ander sig av ett hypervisor f¨or att kunna etablera flera VMs ovanp˚a dess operativsy-stem (OS) [4], se figur 2. Varje VM har sitt egna g¨ast-OS och k¨ors p˚a separata k¨arnor. Hypervisors anv¨ands som en ”brygga” i syfte att f¨orse ett VM med systemresurser fr˚an den fysiska maski-nen [3]. Resursf¨orfr˚agningar fr˚an de virtuella maskinerna hanteras av ett hypervisor som i sin tur kommunicerar med den fysiska h˚ardvaran som ¨ar grunden till hela virtualiseringen.
Figur 1: Uppbyggnaden av traditionellt VM. Det existerar tv˚a olika typer av hypervisor [4]:
• Typ 1 - Alla VM k¨ors direkt p˚a h˚ardvaran, ¨aven kallat bare-metal hypervisor. • Typ 2 - Alla VM k¨ors via operativsystemet, ¨aven kallat hosted hypervisor.
Ett VM kan k¨oras via antingen ett bare-metal hypervisor eller ett hosted hypervisor [5]. Eftersom ”bare-metal” kommunicerar direkt mot h˚ardvaran beh¨ovs inte ett host-OS f¨or att virtualiseringen ska fungera. Bare-metal hypervisor agerar ist¨allet som ett underliggande OS och har sina egna
drivrutiner och integrerar direkt mot h˚ardvarukompontener f¨or exempelvis I/O-processer och OS-relaterade uppgifter. Anv¨andandet av bare-metal hypervisor tillf¨or en b¨attre prestanda, skalbarhet och stabilitet ¨an hosted hypervisor. Hosted hypervisor har ingen direktkoppling till h˚ardvaran utan integrerar ist¨allet med ett host-OS som i sin tur ansvarar f¨or drivrutiner och diverse processer, vilket anses bidra till b¨attre kompatibilitet. Det extra lagret mellan h˚ardvara och hypervisor skapar d¨aremot mer processer i systemet vilket blir mer resurskr¨avande och s¨anker prestandan p˚a de virtuella maskinerna.
2.3
Container-baserad virtualisering
Container-baserad virtualisering tillhandah˚aller virtualisering p˚a operativsystems-niv˚a. Den stora skillnaden fr˚an ett traditionellt VM ¨ar att containers delar samma operativsystemsk¨arna med varandra vilket till˚ater flera applikationer att kunna k¨oras samtidigt utan att beh¨ova ha redundanta operativsystem [4]. En host k¨or exempelvis Linux som underliggande OS och en container-motor som i sin tur skapar containrar f¨or individuella processer [6]. Dessa processer delar sedan samma OS-k¨arna men ¨ar isolerade fr˚an varandra. Container-baserad virtualisering ¨oppnar upp f¨or m˚anga nya m¨ojligheter och tillf¨or modularitet och skalbarhet i den milj¨o tekniken anv¨ands. Ett flertal applikationer, n¨atverkstj¨anster och olika databaser kan k¨oras fr˚an en och samma fysiska server men vara placerade i enskilda containrar som avskiljer dem fr˚an varandra. F¨or att f˚a en visuell bild ¨over hur containrar ¨ar uppbyggda, se figur 2.
Figur 2: Uppbyggnaden av containrar.
Den st¨orsta plattformen f¨or container-baserad virtualisering ¨ar Docker, som ¨ar ett verktyg f¨or att bygga, transportera och k¨ora applikationer i containrar [4].
2.4
Docker
Docker ¨ar f¨or n¨arvarande en av de mest framg˚angsrika containertekniken genom sina nya f¨orm˚agor som tidigare tekniker inte besitter [4]. Docker medf¨or modularitet, skalbarhet och en enklare anv¨andning f¨or att snabbt kunna bygga och testa applikationer i containrar [5].
Docker ¨ar egentligen ett samlingsnamn f¨or ett flertal verktyg som jobbar i union med varandra f¨or att skapa en containermilj¨o och d¨ar de tv˚a viktigaste delarna, Docker client och Docker daemon, samlas under namnet Docker Engine [7].
2.4.1 Docker engine
Docker engine ¨ar k¨arnan i hela virtualserings-processen och ¨ar det lagret som Docker k¨ors fr˚an, i figur 2 ˚aterfinns en visuell representation av hur de olika komponenterna h¨anger ihop. Docker engine k¨ors via ett Linux-system och ¨ar det verktyg som hanterar alla Docker objekt som skapar och driver containrar.
Figur 3: Docker engine.
Docker client ¨ar det prim¨ara s¨attet f¨or anv¨andare att integrera med Docker [7]. Ett Docker REST API anv¨ands f¨or att kunna kommunicera med en eller flera olika Docker daemon via script eller direkta CLI-kommandon.
Docker daemon (dockerd) ¨ar den delen av Docker Engine som g¨or det tyngsta arbetet. Den lyssnar efter API-f¨orfr˚agningar och hanterar alla Docker objekt s˚asom images, containrar, n¨atverk och volymer [7]. En daemon kan ocks˚a kommunicera med andra daemons f¨or att hantera olika tj¨anster.
2.4.2 Docker images
Ett av det viktigaste underliggande objekten inneh˚allande instruktioner som beh¨ovs f¨or att kunna implementera en Docker-container ¨ar Docker images [4]. En image ¨ar en skrivskyddad mall som anv¨ands f¨or att starta containrar[7]. Varje image startar med en bas och andra delar l¨aggs sedan till ovanp˚a denna bas f¨or att kunna utf¨ora uppgiften den blir tilldelad. Ett exempel p˚a detta kan vara en image som anv¨ander Ubuntu som bas och en webapplikation ovanp˚a det med Node.js som mellanvara. Varje image best˚ar allts˚a av flera lager och Docker anv¨ander sig av Union file systems (UFS) f¨or att kombinera dessa lager till ett. UFS ¨ar en filsystem-tj¨anst f¨or Linux, FreeBSD och NetBSD operativsystem som implementerar en union-mount f¨or andra filsystem. Det inneb¨ar att filer och register i olika filsystem (branches) kan s¨attas ihop och skapa ett gemensamt filsystem. Av den anledningen kan olika delar av en image bytas ut eller uppdateras utan att administrat¨oren beh¨over bygga om en hel image utan bara de lager som ¨andras.
Dockerfile F¨or att bygga en image beh¨over Docker instruktioner som ˚aterfinns i en enkel och beskrivande fil som kallas Dockerfile. N¨ar en client skickar en byggf¨orfr˚agan till en daemon l¨aser Docker dessa instruktioner och returnerar en f¨ardig image. Varje instruktion i en Dockerfil skapar ett nytt lager i den f¨ardiga imagen, ett exempel p˚a detta kan ses i Figur 4.
Figur 4: Exempel p˚a en enkel Dockerfile.
Docker l¨aser instruktionerna uppifr˚an och ner och b¨orjar d˚a med FROM ubuntu:latest d¨ar senaste versionen specificeras. Efter att en ansvarig ¨ar angiven kan beroendeprogrammen l¨aggas till med RUN-kommandot och kod-filen med ADD. Slutligen best¨ams hemkatalogen med WORKDIR-kommandot och d¨arefter ¨ar denna image redo f¨or att byggas med ett docker build-kommando. N¨ar Docker sedan byggt klart sin image ¨ar den redo att skeppas ut i Docker-milj¨on som en container.
Docker registry F¨or att hitta och anv¨anda Docker images beh¨ovs en databas att s¨oka i och d¨ar anv¨ands Docker registry [7]. Den publika databasen kallas f¨or Docker hub och p˚a hub.docker.com ˚aterfinns den officiella databasen f¨or f¨ardiga images d¨ar administrat¨orer kan v¨alja vilka tj¨anster som ¨onskas och ladda ner en f¨ardig-konfigurerad image som ¨ar redo f¨or att distribueras. ¨Onskar administrat¨oren att konfigurera sin image ytterligare ¨ar det ocks˚a m¨ojligt. Ut¨over Docker Hub s˚a finns ocks˚a m¨ojligheten att skapa ett eget registry. Detta g¨ors i f¨orsta hand f¨or att se till att endast en viss typ eller version av images k¨ors i en viss milj¨o.
2.5
Orkestrering i Docker
Containrar anv¨ands f¨or att kunna binda, isolera och k¨ora applikationer men beh¨over verktyg f¨or att kunna hanteras och kommunicera med varandra. De tv˚a popul¨araste alternativen till orkestre-ringsverktyg f¨or Docker ¨ar Docker Swarm och Kubernetes.
2.5.1 Docker Swarm
Som noterat tidigare kan Docker Client kommunicera med flera Daemons och en Daemon kan prata med andra Daemons. N¨ar flera av dessa kommunicerar tillsammans kallas detta en Docker Swarm [8]. Docker Swarm ¨ar ett orkestreringsverktyg som finns inbyggt i de senaste versionerna av Docker och har ett antal nyckelfunktioner. Varje Docker-nod kan anta rollen som manager, worker eller utf¨ora b˚ada rollerna samtidigt. N¨ar en administrat¨or skapar en tj¨anst kan denne best¨amma m¨angden kopior som ska k¨oras, och vilka resurser som ska tilldelas respektive kopia. Docker arbetar d¨arefter f¨or att detta tillst˚and ska uppr¨atth˚allas. Om en worker-nod av n˚agon anledning skulle sluta fungera kan Docker s¨aga ˚at en annan nod att ta ¨over den otillg¨angliga nodens uppgift. En uppgift, i det h¨ar fallet, ¨ar helt enkelt en container som ¨ar en del av en Swarm-tj¨anst och hanteras av en Swarm-manager till skillnad fr˚an en ensamst˚aende container.
2.5.2 Kubernetes
Kubernetes ¨ar en flexibel open-source plattform som ¨ar byggd f¨or att underl¨atta konfigurering och hantering av containrar [9]. Kubernetes tillhandah˚aller ett ramverk f¨or att kunna k¨ora distribuerade system och hanterar funktioner som exempelvis skalning och redundans f¨or applikationer som anv¨ands. Ett kluster best˚ar av ett antal maskiner, ¨aven kallat noder, som k¨or isolerade applikationer i containrar och placeras i det som kallas en Pod [10]. Ett kluster best˚ar av minst en master-nod och en worker-nod. Pod ¨ar ett annat ord f¨or en samling av en eller flera containrar som delar samma
n¨atverk, lagring och specifikationer ¨over hur containrar ska k¨oras [11][12]. Genom en distribution av en viss tj¨anst skapas en Pod med containrar p˚a varje nod i syfte att hantera varje instans av applikationen som ska k¨oras.
2.5.3 Arkitekturen i Kubernetes
Kube-apiserver hanterar all kommunikation inom ett kluster och arbetar p˚a master-noden via en s¨aker port [13]. Den ansvarar f¨or att konfigurera resurser och validera allt resursskapande innan resurserna kan genereras. Anv¨andare kommunicerar med API-servern genom kubectl-kommandon. Etcd ¨ar en h¨ogtillg¨anglig och distribuerad lagringsplats f¨or nyckelv¨arden som Kubernetes anv¨ander f¨or att lagra all kluster-konfiguration [13]. Alla resurser och objekt som skapas i Kubernetes sparas i etcd som tillhandah˚aller dess metadata och aktuellt tillst˚and. Etcd kommunicerar endast direkt med API-servern.
Kube-controller-manager anv¨ands f¨or att hantera applikationer i kluster[13]. Dessa control-lers kan beskrivas som kontrol-loopar som hela tiden s¨akerst¨aller att aktuellt tillst˚and f¨or klustret st¨ammer ¨overens med det ¨onskade tillst˚andet. De kollar det aktuella tillst˚anden i etcd genom API-servern f¨or att sedan skapa, uppdatera eller radera efter behov.
Kube-scheduler anv¨ands f¨or att hantera och besluta kring schemal¨aggning f¨or poddar i ett kluster[13]. Besluten beror p˚a ett antal faktorer, exempelvis applikationens resursbehov eller re-surstillg¨anglighet p˚a noder.
Kubelet ¨ar en agent som k¨ors p˚a alla worker-noder i klustret [13]. Kubelet har huvudansva-ret ¨over att hantera alla containrar som befinner sig inuti en pod och se till att aktuellt tillst˚and f¨or containrar matchar det tillst˚and som specificerats i etcd.
Kube-proxy ¨ar en n¨atverksproxy och ¨ar den komponent i Kubernetes som ansvarar f¨or vida-rebefordran av f¨orfr˚agningar. Varje nod i klustret samverkar med Kubernets via kube-proxy. 2.5.4 Kluster-n¨atverk i Kubernetes
F¨or att poddarna i Kubernetes skall kunna kommunicera med varandra beh¨over administrat¨oren ocks˚a installera ett kluster-n¨atverk. Detta n¨atverk existerar tillsammans med v¨ard-datorns vanliga n¨atverksuppkoppling och blir allts˚a bara en ny adress som anv¨ands f¨or att kommunicera i och med Kubernets. Varje pod f˚ar en egen IP-adress vilket inneb¨ar att alla containrar i podden kan kommunicera med alla andra containrar via localhost och att alla containrar i podden m˚aste orkestrera port-nummer f¨or att paketen inte ska krocka p˚a v¨ag till r¨att applikation. Detta ¨ar egentligen samma strategi som anv¨ands i vanliga VM och g˚ar generellt under namnet ”IP-per-Pod”. Det kluster-n¨atverk som m˚aste installeras finns i flertalet olika versioner som alla tillf¨or nya funktioner, eller tar bort s˚adant som kan ses som on¨odigt. M˚anga av de kluster-n¨atverk som finns har funktioner som ¨ar utanf¨or detta arbetes omfattning men nedan f¨oljer tre av de varianter som kan anv¨andas:
• Cilium, som ¨ar en mjukvara med ¨oppen k¨allkod anv¨ands f¨or att s¨akra n¨atverkskommunikation transparent. Cilium verkade intressant att anv¨anda i v˚art projekt d˚a den kan anv¨andas f¨or att s¨atta upp policys hela v¨agen fr˚an lager tre (Network) till lager sju (Applikation) i OSI-modellen och tidigt fanns en id´e om att anv¨anda detta f¨or att testa redundans.
• Flannel, ¨ar ett v¨aldigt simpelt kluster-n¨atverk som i princip bara uppfyller Kubernetes mini-mikrav. Flannel ¨ar f¨orh˚allandevis enkelt att implementera och enligt Kubernetes sj¨alva har m˚anga anv¨andare rapporterat framg˚ang n¨ar de anv¨ant Flannel.
• Romana, som ¨aven detta ¨ar ¨oppen k¨allkod ¨ar en n¨atverks och s¨akerhetsl¨osning som l˚ater anv¨andaren s¨atta upp och k¨ora Kubernetes utan ett kluster-n¨atverk. Romana anv¨ander sig av Kubernetes Network Policy f¨or att isolera trafik ¨over olika n¨atverks namespaces.
2.6
Node.js
Node.js ¨ar en open source-plattform och en server-milj¨o som ¨ar utformad f¨or att bygga skalbara n¨atverksapplikationer med ett stort st¨od f¨or olika moduler och funktioner [14]. Det ¨ar baserat p˚a Javascript och anv¨ands generellt f¨or att generera dynamiskt inneh˚all p˚a webbsidor, hantera filer p˚a servrar samt sk¨ota in och ut-data till databaser. Modulen ”Express” anv¨ands som http-server, vilket ger tillg˚ang till enkel hantering av http-paket.
2.7
HTTP-funktioner
F¨or att skicka information fr˚an en klient till en http-server beh¨over servern vara konfiguererad att hantera de olika http-funktionerna som ¨ar standard idag[15]. Alla f¨ardiga webbservrar har denna funktionallitet inbyggt men d˚a v˚ar applikation ¨ar byggd fr˚an grunden inneb¨ar det att ¨aven pakethantering m˚aste byggas fr˚an grunden. Http har definierade metoder f¨or att skicka och ta emot data som exempelvis POST-funktionen. Med POST-funktionen kan klienten skicka data till servern och f˚a respons tillbaka.
2.8
Amazon Web Services
Amazon Web Services (AWS) ¨ar en s¨akrad molnplattform som tillhandah˚aller moln-tj¨anster s˚a som ber¨akningskraft, databaslagring och annan funktionallitet f¨or privat-personer och f¨oretag[16]. En av dessa moln-tj¨anster ¨ar m¨ojligheten att utforma och sj¨os¨atta egna virtuella maskiner som blir tillg¨angliga genom AWS Management Console. Under utformningsprocessen kan anv¨andaren v¨alja operativsystem, hur mycket minne och hur stark processor som ¨onskas. D¨arefter kan andra modul¨ara delar l¨aggas till eller tas bort, exempelvis n¨atverkskort eller lagringsvolymer. Dessa aspekter g¨or AWS till en acceptabel plattform att utf¨ora olika tester p˚a. Om n˚agon av de instanser som anv¨ands av n˚agon anledning skulle krascha eller p˚a n˚agot s¨att sluta fungera ¨ar skapandet av en ny virtuell maskin trivialt.
3.
Relaterade arbeten
N˚agot som tidigt m¨arktes under s¨okandet efter relaterade arbeten var att majoriteten av alla arbe-ten ¨ar publicerade under de senaste tv˚a ˚aren. Detta kan h¨arledas till att container-orkestrering ¨ar en f¨orh˚allandevis ny teknik, och d¨arf¨or har s¨okandet efter relaterade arbeten varit mer anstr¨angande ¨
an om arbetet handlat om mer vedertagen teknik. Det inneb¨ar ocks˚a att ¨aven om dessa resultat ¨
ar referensgranskade och v¨alarbetade s˚a tror vi att det ¨an s˚a l¨ange ¨ar f¨or lite arbete gjort inom detta f¨alt f¨or att det ska finnas en ordentligt cementerad uppfattning om vad som egentligen ¨ar de b¨asta verktyget. Med det sagt s˚a har de arbeten vi funnit alla konstaterat ungef¨ar samma sak; Kubernetes ¨ar den mest kompletta l¨osningen f¨or container-orkestrering, ¨aven om den ocks˚a verkar ha h¨ogst inl¨arningskurva.
N. Marathe et al. [17] beskriver skillnaden mellan verktygen Docker Swarm och Kubernetes sett till bland annat prestanda, flexibilitet och feltolerans. Genom en upps¨attning av tre stycken noder, en master/manager och tv˚a worker-noder f¨or vardera verktyg, k¨ordes en webbtj¨anst som applicerats p˚a alla noder. Deras tester resulterade i en slutsats d¨ar Kubernetes visade sig vara det b¨attre alter-nativet vad g¨aller CPU- och minnesprestanda samt andra m¨atpunkter som presenterades genom en tabell i figur 5.
Figur 5: Skillnader mellan Docker Swarm och Kubernetes [17].
En annan studie som har gjorts kring Docker Swarm och Kubernetes presenteras i ett arbete skrivet av A. Modak et al. [18]. Deras slutsatser baseras helt p˚a en djupg˚aende litter¨arstudie kring skillnader mellan verktygen n¨ar det kommer till datas¨akerhet. ¨Aven h¨ar framst˚ar Kubernetes som det sj¨alvklara valet, exempel p˚a punkter som tas upp:
• Kubernetes ¨ar ett kraftfullare verktyg ¨an Docker Swarm n¨ar det kommer till skalbarhet och automatisering.
• Kubernetes har ett inbyggt biblotek f¨or ¨overvakning och loggning j¨amf¨ort med Docker Swarm d¨ar tredjepartsapplikationer beh¨ovs anv¨andas.
• Kubernetes hanterar ˚ateruppbyggnad av krashade noder. • Kubernetes har b¨attre prestanda.
• Nackdelen med Kubernetes ¨ar den komplexa installtaionsprocessen d¨ar Docker Swarm anses vara enklare att hantera.
I en artikel av I. M. A. Jawarneh et al. [19] gjordes en j¨amf¨orelse av fyra olika orkestreringsverktyg d¨aribland Docker Swarm och Kubernetes men ¨aven Cattle och Apache Mesos. I deras test anv¨ander de sig av tre olika applikationer med ¨okande m¨angd krav p˚a antal containrar. Det kan j¨amf¨oras med detta arbete d¨ar vi begr¨ansat oss till en applikation med en container. Deras j¨amf¨orele grundar sig i fyra olika m¨atpunkter; skalbarhet, tid f¨or tillhandah˚allande, skillnaden mellan tillhandah˚allande n¨ar Docker image ˚aterfinns lokalt p˚a v¨ardmaskinen kontra om den ligger p˚a ett privat register samt redundans. Slutsatsen som n˚as i detta arbete pekar p˚a Kubernetes som den mest komplet-ta l¨osningen f¨or container-orkestrering, ¨aven om Kubernetes ¨ar marginellt l˚angsammare n¨ar det kommer till omstart av ensamst˚aende containrar. Detta beror intressant nog p˚a att Kubernetes ¨ar eventstyrt snarare ¨an hj¨artslagsbaserat som bl.a. Docker Swarm vilket g¨or att omstart av enskilda containrar tar l¨angre tid.
Y. Pan et al. [20] presenterar en prestandaj¨amf¨orelse mellan Docker Swarm och Kubernets samt hur dessa orkestreringsverktyg kan anspassas i olika milj¨oer. I arbetet redovisas en rad tester som gjorts f¨or att m¨ata prestandakostnader och identifiera generella f¨or- och nackdelar med orkestringings-verktygen. N˚agra exempel p˚a viktiga slutsatser som tas upp: Docker Swarm ¨ar enkelt att distribuera och konfigurera med andra komponenter eftersom Docker Swarm ¨ar inbyggt i Docker. Kubernetes, som ett tredjepartsverktyg, ¨ar ˚a andra sidan mer komplext men ocks˚a mer omfattande och moget n¨ar det kommer till funktionalitet och att fungera b¨attre i olika produktionsmilj¨oer. Komponen-terna i Kubernetes ¨ar inte n¨odv¨andigtvis dyra att anv¨anda men den infrastruktur som beh¨ovs kan bli dyr n¨ar kommer till sm˚askaliga kluster. D¨aremot ¨ar Kubernetes det optimala verktyget i st¨orre infrastrukturer p˚agrund av sin auto-skalning d˚a verktyget ist¨allet kan f˚a ut maximalt av sina re-surser. Majoriteten av deras tester p˚avisar att Docker Swarm har mycket l¨agre prestandakostander ¨
an Kubernetes, med undantag f¨or de tester som gjort p˚a storskaliga kluster.
Ytterligare arbeten har gjorts som handlar specifikt om de kluster-n¨atverk som finns tillg¨angliga f¨or Kubernetes och Docker Swarm. Det ¨ar allts˚a dessa kluster-n¨atverk som sk¨oter kommunikatio-nen mellan noderna. I en studie av H. Zeng et al. [21] j¨amf¨ors tre olika kluster-n¨atverk med fokus p˚a genomstr¨omning av trafik, b˚ade UDP och TCP. De kluster-n¨atverk de unders¨oker ¨ar Calico, Flannel och Swarm Overlay. Deras arbete ¨ar intressant att j¨amf¨ora med detta d˚a valet av kluster-n¨atverk kan p˚averka prestandan i klustret. Enligt Zeng et al. ¨ar Calico ett snabbare n¨atverk men kr¨aver mer konfigurering kontra Swarm Overlay eller Flannel. I v˚art fall har vi f¨or Docker Swarm anv¨ant just Swarm Overlay och Flannel f¨or Kubernetes, men arbetet utf¨ort av Zang et al. lyfter fr˚agan om resultatet av v˚ar unders¨okning kan ¨andras om ett annat kluster-n¨atverk anv¨ands under implementationen av Kubernetes.
4.
Metod
F¨or att n˚a ett resultat med starka grunder och bevis har denna studie delats upp i tv˚a delar: • En analytisk unders¨okning av den dokumentation som existerar kring respektive verktyg ger
oss kvalitativ data. Genom kritiskt t¨ankande kan vi j¨amf¨ora verktygens officiella dokumenta-tion, granskade rapporter och ¨ovriga ˚asikter uttryckt av andra anv¨andare f¨or att avg¨ora vilka av programmens funktioner vi b¨or unders¨oka samt hur andra anv¨andare ser p˚a verktygen. • En samling experiment som i sin tur ger oss kvantitativ data som sammanst¨alls som statistik.
Denna metod g¨or att vi enkelt kan se vad som ¨ar normalt beteende och vad som ¨ar anomalier. Motiveringen f¨or att anv¨anda dessa tv˚a metoder kommer dels fr˚an H˚akanssons[22] genomg˚ang av vetenskapliga tillv¨agag˚angss¨att d¨ar vi letade efter n˚agonting som passade de fr˚agest¨allningar vi tagit fram. H˚akansson[22] menar att ett av de b¨attre s¨atten att hantera stora m¨angder data ¨ar att sammanst¨alla den i statistik, vilket ¨ar vad vi har valt att g¨ora f¨or att f˚a fram data ur v˚ara experiment. H˚akansson menar ocks˚a att empirisk forskning anv¨ands f¨or att samla kunskap och data genom experiment, observationer och upplevelser. Datan analyseras sedan genom kvalitativa eller kvantitativa metoder. Lisa M. Given [23] medger ocks˚a i sin tur att kvantitativa metoder ¨ar en del av en empirisk unders¨okning som inneb¨ar att samla in, analysera och presentera data i numerisk form.
4.1
Analytisk unders¨
okning
Den analytiska unders¨okningen b¨orjade med att vi tittade p˚a den officiella dokumentationen f¨or respektive verktyg d¨ar vi dels unders¨okte vilka funktioner dessa verktyg hade samt hur l¨attl¨ast do-kumentationen f¨oref¨oll. Som referens f¨or vad som ¨ar ”l¨attl¨ast” anv¨ande vi oss av v˚ara egna erfaren-heter av att l¨asa tekniska dokument och rapporter under v˚ar tre˚ariga utbildning i n¨atverksteknik. I n¨asta steg l¨aste vi och analyserade granskade rapporter och arbeten som var relaterade till v˚art eget. Det ¨ar en kombination av kvalitativa och kvantitativa rapporter och arbeten som ocks˚a ¨ar utf¨orda f¨or att j¨amf¨ora Kubernetes och Docker Swarm. Vi analyserade dessa f¨or att avg¨ora vilket av alla programmens funktioner som var viktigast att unders¨oka. Avslutningvis unders¨okte vi vad andra anv¨andare skrivit om programmen p˚a hemsidor d¨ar expertis kring dataveteskap samlas n¨amligen Slack, GitHub och Stackoverflow. Vi valde att anv¨anda oss av denna analytiska unders¨okning d˚a vi beh¨ovde skapa oss en uppfattning om hur verktygen fungerade, hur vi skulle testa dem samt hur de upplevdes av andra anv¨andare f¨or att kunna genomf¨ora testerna p˚a ett korrekt s¨att.
4.2
Experiment
N¨ar den analytiska unders¨okningen var avklarad kunde vi sammanst¨alla vilka delar av verktygen som vi skulle testa. F¨or att j¨amf¨ora verktygen p˚a ett likv¨ardigt s¨att anv¨ande vi oss av virtuell utrustning hos en betrodd leverant¨or (Amazon Web Services) f¨or att ha full kontroll p˚a de virtu-ella maskinernas prestanda. I tabell 1 visas information om h˚ardvara och mjukvara staplade f¨or att experimenten l¨att ska kunna efterliknas. Docker Swarm och Kubernetes k¨orde p˚a T3.Micro instanser medans Windows Server k¨ordes p˚a T3.Xlarge.
Program Version Docker 19.03.4 Kubernetes 1.16.2 Node.JS 13.0.0 Postman 7.10.0 Ubuntu 18.04 Windows Server 10.0.17763
EC2 T3.Micro EC2 T3.Xlarge Processor 2st vCPU 2.5Ghz 4st vCPU 2.5Ghz
RAM-minne 1024MB 16384MB
N¨atverk Upp till 5Gbit/s Upp till 5Gbit/s
De relaterande arbetena vi tittat n¨armre p˚a har redovisat skillnader i verktygens funktionalitet och prestanda men fokuserar d˚a f¨or det mesta p˚a verktygens f¨orm˚aga och kraft. Det h¨ar arbetet gick ut p˚a att hitta m¨atpunkter som testar och j¨amf¨or verktygen n¨ar det kommer till prestanda d¨ar tid ¨ar fokusomr˚adet.
Valet av de tre testerna utgick fr˚an den liter¨ara analysen vi utf¨orde. Det framgick att dessa verk-tygs prim¨ara uppgift ¨ar att skapa just redundanta och aktivt formbara milj¨oer som snabbt kan ¨
andras f¨or att hantera mer eller mindre arbetslast. Det viktigaste punkterna f¨oref¨oll d˚a vara tiden det tar f¨or en nod att ta ¨over en tj¨anst (redundans), tiden det tar att flytta en aktiv tj¨anst till en ny nod (migrering) samt tiden det tar att skala upp en tj¨anst f¨or att hantera st¨orre arbetslas-ter (applikationsskalning). Redundans en viktig del att j¨amf¨ora eftersom det i grund och botten handlar om en s¨akerhet att verktygens redundanstid ¨ar l˚ag, speciellt n¨ar det kommer till kritiska system. Testerna i migrering och applikationsskalning j¨amf¨or i sin tur verktygens prestanda sett till hantering och distribuering av tj¨anster.
Experimenten utformades i s˚a liten skala som m¨ojligt f¨or att se till att eliminera s˚a m˚anga ut-omst˚aende variabler som m¨ojligt. Minsta m¨ojliga skala inneb¨ar att varje arbetande nod f˚ar en egen virtuell instans f¨or att se till att noderna inte stj¨al prestanda av varandra. D¨arefter begr¨ansas tj¨ansten till en container och en applikation, som dessutom ¨ar en applikation som vi designat sj¨alva f¨or att endast sk¨ota en specifik uppgift. De kommandon som exekveras f¨or att utf¨ora uppgiften ¨ar tagna direkt fr˚an den officiella dokumentationen och hur respektive utvecklare menar att uppgiften ska utf¨oras. P˚a detta s¨att kan vi garantera att uppgiften ¨ar utf¨ord s˚a effektivt som m¨ojligt och att skillnaden i resultatet mellan verktygen inte beror p˚a hur vi instruerat verktyget att utf¨ora uppgiften.
Resultatet av experimenten sammansattes i ett dokument och anv¨andes sedan f¨or att skapa sta-tistik ¨over verktygens beteende. Genom att presentera denna statistik i histogram ¨ar det enkelt att se vilka resultat som kan r¨aknas som normalt beteende och vad som ¨ar anomalier.
5.
J¨
amf¨
orelse av orkestreringsverktyg
Den h¨ar delen kommer presentera det praktiska arbetet vi gjort f¨or att uppn˚a ett resultat. Inled-ningvis b¨orjar vi med en genomg˚ang av de f¨orberedande momenten, installation och konfigurering av orkerstreringsverktygen. Slutligen presenteras de tester vi utf¨ort f¨or vardera orkerstreringsverk-tyg tillsammans med metoden vi anv¨ant f¨or att utf¨ora dem.
5.1
Amazon Web Services
F¨or att snabbt och modul¨art skapa och hantera de virtuella instanser som beh¨ovdes f¨or testerna anv¨andes Amazon Web Services (AWS), specifikt Amazon Elastic Compute Cloud (EC2)[16][24]. Utformandet av en EC2-instans sker genom Amazon Management Console och processen g˚ar ige-nom ett antal steg innan instansen ¨ar redo att startas. F¨orsta steget ¨ar att v¨alja operativsystem, i detta fall Ubuntu 18.04 och Windows Server 2019. D¨arefter valdes en T3.Micro instans som ger den virtuella maskinen tillg˚ang till tv˚a virtuella CPU-k¨arnor och 1GB RAM vilket t¨ackte de krav vi ha-de inf¨or projektet. Slutligen tillkommer konfiguration av s¨akerhetsgrupper och subn¨ats-tillh¨orighet f¨or att enheterna skall kunna kommunicera sinsemellan. I v˚art test valde vi en upps¨attning av tre EC2-instanser som agerar noder f¨or respektive orkestreringsverktyg samt en utomst˚aende klient med Windows f¨or de b˚ada, som var ansvarig f¨or att skicka paket till test-applikationen. D˚a vi tidigt m¨arkte att Windows-maskinen beh¨ovde mer prestanda skapades dessa instanser om som T3.XLarge vilket ist¨allet ger tillg˚ang till 4 virtuella CPU-k¨arnor och 16GB RAM.
5.2
F¨
orberedande installationer
Innan vi b¨orjade med alla tillh¨orande installationer konfigurerade vi filen /etc/hosts p˚a alla noder f¨or att koppla namn till IP-adresser, se figur 6, vilket underl¨attade arbetet i senare faser.
Figur 6: IP-adresser p˚a noder f¨or respektive orkestreringsverktyg.
5.2.1 Installation av Docker och Docker Swarm
Vi installerade f¨orst Docker p˚a alla instanser och anv¨ande oss av docker.io-paketet eftersom det anv¨ands f¨or att installera officiella docker-releaser f¨or Debian [25]. Sedan f¨oljde vi dokumentationen p˚a Dockers egen hemsida f¨or att s¨atta upp Docker Swarm [26].
Docker installerades genom sudo apt install docker.io och aktiveras genom sudo systemctl enable docker, dessa tv˚a kommandona m˚aste k¨oras p˚a alla de noder som senare ska ing˚a i Docker Swarm.
Ef-tersom Docker Swarm ¨ar inbyggt i Docker s˚a ¨ar installtionsf¨orloppet v¨aldigt simpelt. Komman-dona f¨or att skapa och s¨atta upp Docker Swarm kan ses i bilaga A och som initierades genom endast ett kommando p˚a en nod som sedan f¨orblir manager. Genom detta kommando genere-ras en ”Swarm token” som anv¨ands f¨or att l¨agga till andra noder (”workers”) i Swarm. Genom kommandot sudo docker node ls p˚a manager listas alla aktiva noder i Swarm, se figur 7.
5.2.2 Installation av Docker och Kubernetes
Eftersom det inte fanns n˚agon officiell dokumentation f¨or en installationsguide p˚a Kubernetes egna hemsida s˚a fick vi leta efter andra trov¨ardiga guider p˚a internet. Vi hittade tre stycken k¨allor som presenterade samma installationsguide, som vi ocks˚a valde att f¨olja [27][28][29].
Docker installerades och aktiverades p˚a samma s¨att som n¨amndes tidigare, genom kommandona sudo apt install docker.io och sudo systemctl enable docker. Installationsf¨orloppet och alla dess tillh¨orande kommandot f¨or respektive nod kan ses i bilaga B. Kubernetes installerades genom att h¨amta ner Kubernetes signerings-nyckel, datakatalog och sedan installera Kubeadm p˚a alla noder som ska ing˚a i klustret. Kubernetes initierades sedan p˚a den nod som ska agera master genom ett kommando d¨ar en specifik IP-adress f¨or kluster-n¨atverket anges. Genom kommandot genereras sedan en ”join token”, som anv¨ands p˚a de noder som ska ansluta sig till klustret som worker, och tre specifika kommandon som beh¨over skrivas in p˚a master f¨or att l¨agga till r¨attigheter f¨or konfigurationsfiler. Det sista steget f¨or ett fungerade kluster ¨ar att applicera ett kluster-n¨atverk som anv¨ands f¨or kommunikationen mellan noder inom ett Kubernetes kluster, i v˚art fall valde vi kluster-n¨atverket Flannel. Genom kommnandot kubectl get nodes p˚a master-noden listas alla aktiva noder i klustret, se figur 8.
Figur 8: Lista ¨over aktiva noder.
5.2.3 Node.js
F¨or att kunna testa orkestreringsverktygen beh¨ovde vi n˚agonting att k¨ora p˚a noderna. Detta program hade tv˚a solida krav som beh¨ovde uppfyllas; l¨attviktigt s˚a att byggandet av en Docker-image inte skulle ta l˚ang tid att skapa, ladda ner eller ladda upp samt i sin natur vara f¨orh˚allandevis enkelt s˚a att fels¨okning inte tog l˚ang tid. Ett s¨att att uppfylla dessa krav var att bygga en enkel webbserver i Node.js tillsammans med modulen Express som ¨oppnar upp f¨or hantering av http-paket. I applikationen finns tv˚a viktiga funktioner; den f¨orsta funktionen kallas n¨ar en klient g¨or en POST-f¨orfr˚agan till servern varp˚a servern s¨atter en tidsst¨ampel p˚a mottaget paket och skickar tillbaka informationen till klienten. F¨or att spara informationen kallas den andra funktionen som tar in det globalt unika ID satt av Postman tillsammans med tidsst¨ampeln och skriver detta till en text-fil lagrat lokalt i containern. Den fullst¨andiga koden till applikationen kan ses i bilaga C. V˚ar Node.js-applikation paketeras sedan ihop med en Dockerfile (bilaga D) och en package.json-fil (bilaga E) [30] vilket resulterar i en f¨ardig Docker-image.
5.2.4 Drifts¨attning av Docker Swarm
Genom kommandot sudo docker build -t xj0bb1/server:final ./ skapade vi en image av filerna: server.js, Dockerfile och package.json som alla m˚aste vara samlade i en och samma mapp p˚a master-noden.
F¨or att kunna distribuera ut en applikation till noder i en Swarm s˚a beh¨over f¨orst samma image fin-nas p˚a alla noder. H¨ar anv¨ands Docker Hub f¨or att lagra en image p˚a en extern plats och f¨or att det ska g˚a smidigt att g¨ora en push/pull fr˚an noder. Vi loggade in p˚a v˚arat redan existerande Docker Hub-konto genom kommandot sudo docker login --username=xj0bb1. Efter det kunde vi skicka v˚ar f¨ardiga image till Docker Hub genom kommandor sudo docker push xj0bb1/server:final f¨or att sedan h¨amta ner samma image till en worker genom kommandot sudo docker pull xj0bb1/server:final.
N¨ar v˚ar image finns p˚a alla noder kan vi skapa en tj¨anst och distribuera ut den till worker-noder. Tj¨ansten namnges till ”app” och tv˚a kopior av den k¨ors p˚a de noder som har rollen worker. Med p-flaggan specificerar vi den publicerade porten, dvs. den port som anv¨andaren ska ansluta till till-sammans med IP-adressen till Swarm. Avslutningsvis v¨aljer vi vilken image som skall anv¨andas. Kommandot som summerar detta ¨ar f¨oljande: docker service create --replicas 2
--name app --constraint node.role==worker -p 80:4444 xj0bb1/server:final Vi kunde sedan se hur v˚ar tj¨anst har distribuerats och k¨ors worker-noderna, se figur 9.
Figur 9: Lista ¨over tj¨anster distribuering i Docker Swarm.
5.2.5 Drifts¨attning av Kubernetes
Distribution av en applikation i Kubernetes sker till en b¨orjan p˚a samma s¨att som i Docker Swarm. En image byggs p˚a samma s¨att, lagring sker via Docker Hub och skickas och h¨amtas p˚a samma vis. Den stora skillnaden ligger i distribuering av tj¨anst, det som i Docker Swarm g¨ors via ett l˚angt kommando g¨ors i Kubernetes enklast via en YAML-fil (YAML Ain’t Markup Language). V˚ar YAML-fil kan ses i bilaga F och via kommandot kubectl create -f serverd.yaml skapas en tj¨anst och drifts¨atter de instruktioner som angivits i YAML-filen. Vi kunde sedan se att det skapas en tj¨anst och att den distribuerats ut till tv˚a worker-noderna, se figur 10.
Figur 10: Lista ¨over tj¨anster och distribuering i Kubernetes.
5.3
Tester
F¨or att testa och j¨amf¨ora Docker Swarm och Kubernetes valde vi att utf¨ora tre olika tester med hundra fall per test. Testerna ¨ar utvalda f¨or att utv¨ardera tre olika aspekter av orkestreringsverkty-gen; applikationsskalning, migrering samt redundans. Testerna utf¨ordes p˚a samma vis f¨or att uppn˚a ett likv¨ardigt resultat. F¨or testerna i applikationsskalning och migrering valde vi att anv¨anda pro-grammet Gnomon, som ¨ar byggt f¨or att m¨ata hur l˚ang tid det tar f¨or ett visst kommando att utf¨oras. F¨or att m¨ata redundansen s˚a anv¨ande vi en separat nod med Windows och programmet Postman installerat. Vi anv¨ande Postman f¨or att kunna skicka ett best¨amt antal http-paket till v˚ar tj¨anst. Windows-noden befinner sig i samma subn¨atverk och har konnektivitet till de andra noderna men ing˚ar inte i Swarm/klustret.
• Applikationsskalning m¨attes genom att skala upp v˚ar tj¨anst fr˚an att k¨ora p˚a en nod till att k¨ora p˚a tv˚a samt att skala ner v˚ar tj¨anst fr˚an tv˚a noder till en f¨or att sedan m¨ata tiden f¨or respektive uppgift. N¨ar skalningen ¨ar f¨ardig utf¨ors ocks˚a en verifiering p˚a fem sekunder som vi r¨aknat bort fr˚an den totala tiden.
• Migrering innebar att m¨ata hur l˚ang tid det tog f¨or en tj¨anst att flytta fr˚an en worker-nod till den andra. N¨ar migreringen ¨ar f¨ardig utf¨ors ocks˚a en verifiering p˚a fem sekunder som vi r¨aknat bort fr˚an den totala tiden.
• Redundans m¨attes genom ett test d¨ar vi skickade http-paket fr˚an Postman till v˚ar tj¨anst i ett konstant fl¨ode. Eftersom det endast ¨ar en worker-nod som aktiv medan den andra ¨ar p˚a ”stand-by” kunde vi simulera en krash p˚a den aktiva noden och m¨ata hur l˚ang tid det tog innan den andra noden blev aktiverad. Som n¨amnts tidigare byggde vi v˚ar applikation att tidst¨ampla varje paket som kommer in fr˚an Postman f¨or att sedan skicka tillbaka tiden som respons. P˚a s˚a s¨att kunde vi m¨ata tiden fr˚an det att sista paketet p˚a f¨orsta noden togs emot till att f¨orsta paketet togs emot p˚a andra noden. I Postman kunde vi ¨aven se antal tappade paket under krashen.
5.3.1 Tester i Docker Swarm
Applikationsskalning i Docker Swarm m¨attes genom kommandona docker service scale app=2 respektive docker service scale app=1 f¨oljt av gnomon --type=elapsed-total f¨or att m¨ata ti-den. Hur detta s˚ag ut fr˚an kommandotolken kan ses i figurerna 11 och 12.
Figur 11: Uppskalning i Docker Swarm.
Figur 12: Nedskalning i Docker Swarm.
Migrering m¨attes genom att starta en tj¨anst p˚a endast en av noderna och sedan anv¨anda script-filerna som kan ses i bilaga G f¨oljt av gnomon --type=elapsed-total. H¨ar g¨ors tv˚a verifieringar p˚a fem sekunder vardera, d¨arav r¨aknar vi bort tio sekunder fr˚an den totala tiden. Hur detta s˚ag ut i kommandotolken kan ses i figurerna 13 och 14.
Figur 13: Migrering fr˚an worker1 till worker2 i Docker Swarm.
Figur 14: Migrering fr˚an worker2 till worker1 i Docker Swarm.
Redundans i Docker Swarm m¨attes i tid genom att simulera en krash och unders¨oka ¨overg˚angen f¨or en tj¨anst mellan noderna. En session av http-paket skickades fr˚an Postman till den aktiva noden som vi sedan krashade genom kommandot killall dockerd. Vi kunde sedan se hur v˚ar tj¨anst direkt blev aktiv p˚a den andra noden. D¨arefter kunde vi l¨asa av tidsst¨amplarna och note-ra f¨ordr¨ojningen mellan sista och f¨orsta paketet samt antal paket som tappades i samband med krashen.
5.3.2 Tester i Kubernetes
Applikationsskalning i Kubernetes utf¨ordes p˚a samma vis som Docker Swarm d.v.s. att ¨andra antal kopior av tj¨ansten. Hur applikationsskalningen i Kubernetes m¨attes i tid kan ses i figur 15.
Figur 15: Upp- och nedskalning i Kubernetes.
Migrering kunde testas genom att f¨orst modifiera YAML-filen (bilaga F) och l¨agga till en no-deselector d¨ar vi helt enkelt kan v¨alja vilken worker-nod som ska k¨ora applikationen fr˚an b¨orjan. Testet utf¨ordes sedan genom att skapa tv˚a patch-filer (bilaga H) som sedan anv¨ands i komman-dot kubectl patch deployment server-deployment --patch "$(cat <patch-fil>)" f¨or att automatiskt modifiera YAML-filen med att byta nodeselector. Hur detta s˚ag ut i kommandotolken kan ses i figur 16.
Figur 16: Migrering i Kubernetes.
Redundans i Kubernetes kunde testas p˚a exakt samma s¨att som i Docker Swarm. Skicka ett fl¨ode med http-paket fr˚an Postman, krasha den aktiva noden genom killall dockerd och sedan l¨asa av f¨ordr¨ojningen mellan sista och f¨orsta paketet samt notera antal tappade paket. Till skillnad fr˚an Docker Swarm beh¨ovde vi inte starta om tj¨ansten d˚a Kubernetes sj¨alv ins˚ag att containern var trasig och startade om den automatiskt. Vad som ocks˚a intressant ¨ar att Kubernetes inte krashade direkt efter att vi skrev in kommandot, utan processen fortsatte k¨oras p˚a den f¨orst aktiva noden i ytterligare ett par sekunder innan containern krashade och startades om. I diskussionsavsnittet av rapporten tar vi upp detta och l¨agger fram id´eer om vad detta beteende beror p˚a.
6.
Resultat
Resultaten presenteras h¨ar nedan i histogram vilket d˚a visar antalet resultat inom ett visst spann. Genom att presentera datan p˚a detta s¨att g˚ar det att utg¨ora vad som kan ses som normalt beteende och vad som ¨ar anomalier.
6.1
Applikationsskalning
Tid i sekunder Antal händelser 0 25 50 75 100 2,00 2,60 3,20 3,80 4,40 5,00 5,60 6,20 6,80 7,40 8,00Figur 17: Skalning fr˚an en nod till tv˚a i Docker Swarm (sekunder).
Tid i millisekunder Antal händelser 0 25 50 75 100 5,00 8,00 11,00 14,00 17,00 20,00 23,00 26,00 29,00 32,00 35,00
Figur 18: Skalning fr˚an en nod till tv˚a i Kubernetes (millisekunder).
I figur 17 ser vi att det i majoriteten av fallen tar Docker Swarm mellan 2,6 och 3,2 sekunder att skala en applikation fr˚an en nod till tv˚a. I figur 18 ser vi att Kubernetes aldrig beh¨over mer ¨an 32 millisekunder f¨or att skala upp en applikation fr˚an en till 2 tv˚a, och majoriteten av fallen ¨ar mellan 5 och 8 millisekunder.
7,328 6,7 10,586 5,7 Tid i millisekunder 0 2 4 6 8 10 12
Medel (Kubernetes) Median (Kubernetes) Medel (Docker Swarm) Median (Docker Swarm)
Figur 19: Skalning fr˚an tv˚a noder till en nod i Kubernetes & Docker Swarm (millisekunder).
I figur 19 blir resultatet avsev¨art n¨armare. Att skala ner en applikation fr˚an tv˚a noder till en ¨
ar Docker enligt median snabbare ¨an Kubernetes. Docker f¨orlorar p˚a medelv¨ardet p˚a grund av utstickande v¨arden p˚a upp emot 180 millisekunder.
6.2
Migrering
Tid i sekunder Antal händelser 0 10 20 30 40 50 60 14,50 14,61 14,72 14,83 14,94 15,06 15,17 15,28 15,39 15,50Figur 20: Migrering av tj¨anst i Docker Swarm (sekunder).
15,0226 15,06 Tid i sekunder 0 5 10 15 20 Medel Median
Figur 21: Migrering av tj¨anst i Docker Swarm (sekunder).
I figur 20 ser vi att det tar Docker Swarm mellan 14,72 och 15,17 sekunder att migrera en applikation fr˚an en nod till en annan. Majoriteten av resultaten infinner sig i spannet mellan 15,06 och 15,17 sekunder. I figur 21 ser vi medel- och median-tid f¨or uppgiften som b˚ada befinner sig kring 15 sekunder.
Tid i millisekunder Antal händelser 0 10 20 30 40 50 60 6,00 6,45 6,90 7,35 7,80 8,25 8,70 9,15 9,60 10,05 10,50
Figur 22: Migrering av tj¨anst i Kubernetes (millisekunder).
6,92 6,6 Tid i millisekunder 0 2 4 6 8 Medel Median
Figur 23: Migrering av tj¨anst i Kubernetes (millisekunder).
I figur 22 ser vi att det tar Kubernetes mellan 6 och 10,5 millisekund att flytta en applikation fr˚an en nod till en annan. Majoriteten av resultaten ˚aterfinns i spannet mellan 6,45 och 6,90 millisekunder och i figur 23 ser vi att detta g¨or att b˚ade median och medel ocks˚a ˚aterfinns d¨ar i n¨arheten, trots avvikande resultat som ¨ar n¨astan dubbelt s˚a h¨oga som median. Precis som testet i applikationsskalning skiljer sig detta resultat markant mellan orkestreringsverktygen
6.3
Redundans
Tid i millisekunder Antal händelser 0 10 20 30 40 55,00 65,00 75,00 85,00 95,00 105,00 115,00 125,00 135,00 145,00 155,00 165,00 175,00 185,00Figur 24: Redundans i Docker Swarm (millisekunder).
Tid i millisekunder Antal händelser 0 10 20 30 40 0,00 25,00 50,00 75,00100,00 125,00 150,00 175,00 200,00 225,00 250,00 275,00 300,00 325,00 350,00 375,00 400,00
Figur 25: Redundans i Kubernetes (millisekunder).
I figur 24 och figur 25 ser vi skillnaden i tid f¨or de tv˚a verktygen att byta aktiv nod n¨ar en av noderna krashar. H¨ar ser vi att Kubernetes oftare har l¨agre resultat ¨an Docker Swarm, men att utstickande resultat fr˚an Kubernetes kan str¨acka sig upp emot 375 millisekunder medans de hos Docker Swarm aldrig f¨orekommer ett resultat ¨over 185.
1,87 8
1 1
Antal förlorade paket
0 2 4 6 8 10 12
Medel (Kubernetes) Max (Kubernetes) Medel (Docker Swarm) Max (Docker Swarm)
Figur 26: Tappade paket i Kubernetes & Docker Swarm (stycken).
Test 1-100 i ordningen de blev utförda
Millisekunder 0 50 100 150 200 250 300 350
Kubernetes Docker Swarm
Figur 27: Gemensam graf f¨or redundanstid i Docker Swarm och Kubernetes (millisekunder). I figur 26 ser vi skillanden p˚a snittm¨angden paket som f¨orloras under driftstoppet innan den andra noden tar ¨over samt vilket som var den maximala antalet paket som tappades. H¨ar visar resultaten tydligt hur Kuberenetes i snitt tappade 0.87 paket mer ¨an Docker Swarm per testfall. Dessutom kan vi se att de maximala antalet paket tappade hos Kubernetes var 8 stycken, medan Docker Swarm aldrig tappade mer ¨an 1. Med referens till figur 27 s˚a ser man att Docker Swarm verkar generellt stabilare i tiden det tar att utf¨ora uppgiften, medans Kubernetes sv¨anger mellan mycket h¨oga och mycket l˚aga resultat. Kubernetes lyckas vid tv˚a tillf¨allen att byta aktiv nod s˚a fort att det varken tappas paket eller tid vid redundans.
7.
Diskussion
Resultatet av arbetet har tydligt visat hur orkestreringsverktygen beter sig och vilken prestanda de har. Under literaturstudien av relaterade och liknande arbetet visade det sig att de arbete vi har gjort antingen inte utf¨orts tidigare i denna form, eller ˚atminstone inte p˚a samma s¨att. Av den anledningen h¨avdar vi att detta arbete kan ha signifikans b˚ade f¨or lekm¨an och systemadminist-rat¨orer n¨ar det kommer till valet av orkestreringsvektyg f¨or dennes arbetsmilj¨o. M˚alet med denna unders¨okning var att f¨ors¨oka avg¨ora vilket av dessa tv˚a orkestreringsverktyg som hade b¨ast pre-standa sett till applikationsskalning, migrering och redundans samt vilket av de tv˚a som var mest intuitivt att arbeta med. Med dessa fr˚agest¨allningar som utg˚angspunkt anser vi att vi uppn˚att ett p˚alitligt resultat som rimligtvis kan ha signifikans i framtiden.
Resultaten av applikationsskalning och migrering blir extra intressant d˚a det skiljer sig s˚a mar-kant mellan verktygen d¨ar Kubernetes arbetar i millisekunder medan Docker Swarm beh¨over hela sekunder. Att unders¨oka detta beteende n¨armare och f¨ors¨oka utr¨ona vad det beror p˚a ¨ar utanf¨or omfattningen av denna studie men vi har en id´e om att resultatet av migreringstestet beror p˚a Kubernetes anv¨andning av poddar. Oavsett om en worker-nod har en aktiv container eller inte s˚a existerar worker-noden fortfarande som en pod hos Kubernetes, vilken i sin tur inneb¨ar att den ¨
ar redo att drifts¨atta nya tj¨anster snabbare. Detta beteende skiljer sig fr˚an Docker Swarm d¨ar en nod som inte har en container inte heller ¨ar aktiv, annat ¨an f¨or att omdirigera trafik till den aktiva noden.
Varf¨or det g˚ar s˚a mycket fortare f¨or Kubernetes att skala upp en applikation fr˚an en nod till tv˚a torde rimligtvis ¨aven det vara kopplat till Kubernetes hantering av tj¨anster, drifts¨attning och pod-dar men d¨ar har vi ingen direkt id´e om vad det exakt beror p˚a.
Resultatet av redundanstestet var f¨orv˚anande efter den literaturstudie vi gjort innan de prak-tiska arbetet, framf¨orallt det faktum att resultaten pendlade s˚a kraftigt mellan h¨ogt och l˚agt. Enligt litteraturen vi l¨ast f¨oref¨oll det rimligt att Kubernetes skulle vara markant snabbare i alla tester men beteendet vi observerade visade att Kubernetes, ˚atminstone p˚a liten skala, inte alls var lika stabilt som Docker Swarm. Kubernetes uppf¨orande under sj¨alva testet f¨oref¨oll ocks˚a udda, d˚a containern ibland st¨angdes av direkt men oftast tog flera sekunder p˚a sig att krasha efter att vi exekverat kommandot f¨or att st¨anga av processen. Detta beteende skiljer sig markant fr˚an Docker Swarm som i 100% av fallen krashade containern s˚a fort vi k¨orde kommandot. Efter ytterligare unders¨okningar fann vi en anledning till varf¨or i ett av de relaterade arbetena. Mashhour Al Ja-warneh et al [19] skriver i diskussionen kring sina resultat att:
”Kubernetes approach is event-based, and the Kubernetes object is notified by the Kubernetes con-troller when the number of pods changes. That chain effect is the reason for the highest failover time value with Kubernetes. Docker Swarm and Cattle, instead, exploit the heartbeat functionality of the Docker architecture and that allows them to provide the shortest failover time”.
Detta f¨orklarar till viss del varf¨or vi s˚ag s˚a h¨oga resultat under redundanstestet av Kubernetes, och ger oss en id´e om varf¨or resultaten pendlar. Det finns en m¨ojlighet att de kommando vi exekverar i vissa av fallen hamnar i synk med Kubernetes metod f¨or att unders¨oka om en pod ¨ar trasig. De f˚a g˚anger dessa tv˚a saker h¨ander samtidigt n˚ar vi v¨aldigt l˚aga resultat men i majoriteten av fallen v¨antar Kubernetes p˚a en ny h¨andelse f¨or att f¨orst˚a att podden ¨ar trasig och startar d¨arefter om den. Det g˚ar ocks˚a att anta att s¨attet vi krashar containrarna p˚a har med resultatet att g¨ora. Det kommando vi exekverar avslutar processen kopplad till Docker Daemon, vilket har en direkt kopp-ling till Docker Swarm men inte till Kubernetes. I Kubernetes kan avslutandet av den processen ses som att en viktig komponent tas bort vilket efter en viss tid resulterar i en omstart av containern. I Docker Swarm betyder d¨aremot en avslutning av Docker Daemon att noden inte l¨angre existerar i Docker Swarm och d¨arf¨or blir direkt otillg¨anglig.
En alternativ metod att utf¨ora detta test hade varit att genom Amazon Management Console skicka en s˚akallad Diagnostic Interupt som orsakar en Kernel Panic eller bl˚ask¨arm hos en
virtu-ell EC2 instans. Problemet med detta tillv¨agag˚angss¨att ¨ar att instansen med st¨orsta sannolikhet m˚aste byggas om inf¨or varje test. Det betyder i sin tur att de hundra tester vi utf¨ort f˚ar en markant ¨
okning i tid, vilket det inte fanns tillr¨ackligt av f¨or att det skulle vara en rimlig l¨osning.
Forts¨attningsvis ¨ar det viktigt att po¨angtera att Kubernetes innehar vissa funktioner som kan ses som nyttiga, trots att det i detta fall visade sig vara l˚angsammare ¨an sin konkurrent. Kuber-netes ¨ar n¨amligen sj¨alvl¨akande d.v.s. n¨ar vi exekverat kommandot f¨or att krasha en container s˚a bygger Kubernetes om containern efter ett par sekunder. Detta beteende skiljer sig fr˚an Docker Swarm d¨ar vi var tvungna att starta om tj¨ansten efter varje krash.
Att f¨orst˚a verktygens olika funktioner kunde vi l¨asa oss till men att arbeta rent praktisk med verktygen gav oss en djupare f¨orst˚aelse kring anv¨andarv¨anlighet. F¨or oss som var relativt nya in-om ¨amnet konstaterades snabbt att Docker Swarm var betydligt mer l¨attarbetat ¨an Kubernetes. N˚agot som utm¨arkte sig som en stor skillnad mellan orkestreringsverktygen var dess tillh¨orande dokumentation d¨ar Docker Swarm ocks˚a ligger i framkant. P˚a Dockers egna hemsida finns det ett stort utbud av dokumentation om Docker Swarm vilket bidrog till en smidig installation och konfiguration av verktyget. Konfiguration- och installationsmomentet av Kubernetes tog d¨aremot avsev¨art l¨angre tid att utf¨ora p˚a grund av den d˚aliga dokumentationen. Kubernetes egna hemsida var inte till n˚agon st¨orre nytta och slutligen, efter en tids s¨okande, fick vi ist¨allet anv¨anda oss av andra utomst˚aende k¨allor med relevanta guider.
7.1
Begr¨
ansningar som kan p˚
averkat resultatet
I b¨orjan av av det praktiska arbetet var grundtanken att anv¨anda oss av fysisk utrustning att utf¨ora v˚ara tester p˚a. Snabbt m¨arkte vi att det blev sv˚art att l¨osa och vi fick ist¨allet anv¨anda oss av virtuell utrustning via Amazon Web Services, om detta p˚averkat resultatet kan vi inte utesluta. V˚art test ¨ar ocks˚a f¨orh˚allandevis sm˚askaligt d˚a vi endast anv¨ant oss av tre noder per kluster. Det vi visste innan testerna var att Docker Swarm ¨ar byggt f¨or att vara simpelt och fungerar b¨ast i mindre skala medans Kubernetes f˚ar ut sin fulla potential i st¨orre skalor. Eftersom detta var ett j¨amf¨orelsetest med lika grunder kan vi bara presentera ett resultat d¨ar verktygen behandlas likv¨ardigt. Vi valde ocks˚a att endast arbeta med en applikation f¨or att testa verktygen och p˚a grund av detta s˚a kan vi inte veta om resultatet av testerna hade sett annorlunda ut om vi anv¨ant fler. Applikationen ¨ar dessutom relativt liten och l¨atthanterlig f¨or att vi skulle kunna l¨agga mer fokus och tid p˚a sj¨alva testerna.
8.
Slutsatser
Genom en kombination av kvalitativa och kvantitativa tester har vi unders¨okt vilket av de tv˚a mest popul¨ara orkestreringsverktygen f¨or Docker som presterar b¨ast enligt v˚ara m¨atpunkter samt vilket verktyg som ¨ar enklast att arbeta med. Resultatet av unders¨okningen summeras i tabell 2 och visar att f¨or applikationsskalning och migrering ¨ar Kubernetes de b¨attre valet. Endast i det specifika fallet d¨ar vi skalade ner en applikation fr˚an tv˚a noder till en kan Docker Swarm konkurera med Kubernetes. Docker Swarm ˚a andra sidan har ett j¨amnare resultat vid redundanstestning och ¨
ar enligt v˚ar uppfattning mycket enklare att arbeta med.
J¨amf¨orelsetest Docker Swarm Kubernetes ”Vinnare”
Applikationsskalning 7 3 Kubernetes
Migrering 7 3 Kubernetes
Redundans 3 7 Docker Swarm
Anv¨andarv¨anlighet 3 7 Docker Swarm Tabell 2: ¨Overblick ¨over resultat.
Vad som ocks˚a ¨ar viktigt att po¨angtera ¨ar Kubernetes f¨orm˚aga att automatisera uppgifter. Vi uppt¨ackte under testandet av redundans att tj¨ansterna driftsatta hos Kubernetes inte beh¨ovde startas om inf¨or varje test d˚a en sj¨alvl¨akande egenskap fanns inbyggd redan fr˚an start. Trots denna egenskap h¨avdar vi ¨and˚a att Docker Swarm ¨ar det b¨attre verktyget f¨or redundanta l¨osningar d˚a det i vissa fall tog Kubernetes alldeles f¨or l˚ang tid att byta aktiv nod.
Det blir d¨arf¨or en definitionsfr˚aga om vilket orkestreringverktyg som ¨ar det b¨asta d˚a Kubernetes hanterar vissa saker b¨attre medan Docker Swarm ¨ar f¨ordelaktig att anv¨anda i andra sammanhang. Vi menar att Docker Swarm l¨ampar sig b¨ast i mindre milj¨oer d¨ar l¨atthanterlig administrering v¨arderas h¨ogt samtidigt som Kubernetes ¨ar det optimala valet f¨or milj¨oer d¨ar effektivitet f¨or drifts¨attning och underh˚all f¨or nya tj¨anster ¨ar den viktigaste egenskapen. Vi anser ocks˚a Docker Swarm ¨ar det klart b¨attre alternativet om man som lekman ¨amnar ge sig in i containervirtualisering d˚a dokumentationen och resurstillg¨angligheten ¨ar avsev¨art b¨attre.
8.1
Framtida arbeten och f¨
orb¨
attringar
Om detta arbete i framtiden ska forts¨attas ¨ar det f¨orsta steget att ut¨oka skalan p˚a testerna, inkludera fler noder och andra applikationer. Fler noder inneb¨ar st¨orre arbetsb¨orda f¨or orkest-reringsverktyget och kan d¨armed ¨andra resultatet. En annan aspekt ¨ar det specifika s¨attet som anv¨ands f¨or att krasha noder. I v˚art fall exekverade vi ett kommando som avslutade en specifik process men resultatet kan komma att ¨andras om kraschen simulerats p˚a ett annat s¨att, genom exempelvis str¨omavbrott eller Kernel Panic. Avslutningsvis vill vi understryka att dessa verktyg har en m¨angd funktioner som inte inkluderats eller testats i denna studie och som kan p˚averka rekommendationen f¨or specifika f¨orh˚allanden och omr˚aden.
Referenser
[1] “What is virtualization?” 2019. [Online]. Available:
https://www.vmware.com/solutions/virtualization.html
[2] “Vad ¨ar virtualisering?” 2019. [Online]. Available:
https://www.citrix.se/glossary/what-is-virtualization.html
[3] B. Golden, Virtualization for dummies. Wiley Publishing, Inc., 2011. [4] T. Bui, “Analysis of docker security,” 2015, arXiv preprint arXiv:1501.02967.
[5] P. Kasireddy, “A beginner-friendly introduction to containers, vms and docker,” 2016. [Online]. Available: https://www.freecodecamp.org/news/
a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b/#.448r2l4cc
[6] “What is a container?” 2019. [Online]. Available:
https://www.docker.com/resources/what-container
[7] “Docker overview,” 2019. [Online]. Available:
https://docs.docker.com/engine/docker-overview/?fbclid=
IwAR0DnpKNS5NyHRx8MkC1ST-mc4EFmYCbEvCsrRpJxG6zua1yDA4V2825aJE
[8] “Swarm mode key concepts,” 2019. [Online]. Available:
https://docs.docker.com/engine/swarm/key-concepts/
[9] “What is kubernetes,” 2019. [Online]. Available:
https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
[10] “Kubernetes components,” 2019. [Online]. Available:
https://kubernetes.io/docs/concepts/overview/components/
[11] “What is a pod?” 2019. [Online]. Available:
https://kubernetes.io/docs/concepts/workloads/pods/pod/#what-is-a-pod
[12] “Viewing pods and nodes,” 2019. [Online]. Available:
https://kubernetes.io/docs/tutorials/kubernetes-basics/explore/explore-intro/
[13] R. Mandaogane, “Introduction to kubernetes architecture,” 2019. [Online]. Available:
https://rancher.com/learning-paths/introduction-to-kubernetes-architecture/
[14] “About node.js .” [Online]. Available:R https://nodejs.org/en/about//
[15] R. Fielding, UC Irvine, J. Gettys, J. Mogul, DEC, H. Frystyk, MIT/LCS, and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1,” Internet Requests for Comments, RFC Editor, RFC 2068, January 1997. [Online]. Available:
https://tools.ietf.org/html/rfc2068
[16] “What is aws,” 2019. [Online]. Available:https://aws.amazon.com/what-is-aws/
[17] N. Marathe, A. Gandhi, and J. M. Shah, “Docker swarm and kubernetes in cloud computing environment,” pp. 179–184, 2019, 3rd International Conference on Trends in Electronics and Informatics (ICOEI).
[18] A. Modak, S. D. Chaudhary, P. S. Paygude, and S. R. Ldate, “Techniques to secure data on cloud: Docker swarm or kubernetes?” pp. 7–12, 2018, second International Conference on Inventive Communication and Computational Technologies (ICICCT).
[19] I. M. A. Jawarneh, P. Bellavista, F. Bosi, L. Foschini, G. Martuscelli, R. Montanari, and A. Palopoli, “Container orchestration engines: A thorough functional and performance comparison,” in ICC 2019 - 2019 IEEE International Conference on Communications (ICC), May 2019, pp. 1–6.
[20] Y. Pan, I. Chen, F. Brasileiro, G. Jayaputera, and R. Sinnott, “A performance comparison of cloud-based container orchestration tools,” in 2019 IEEE International Conference on Big Knowledge (ICBK), Nov 2019, pp. 191–198.
[21] H. Zeng, B. Wang, W. Deng, and W. Zhang, “Measurement and evaluation for docker container networking,” in 2017 International Conference on Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC), Oct 2017, pp. 105–108.
[22] A. H˚akansson, “Portal of research methods and methodologies for research projects and degree projects,” Proceedings of the International Conference on Frontiers in Education: Computer Science and Computer Engineering FECS, pp. 67–73, 2013.
[23] L. M. Given, “The sage encyclopedia of qualitative research methods,” 2008, Sage Publications.
[24] “Amazon ec2,” 2019. [Online]. Available:https://aws.amazon.com/ec2/
[25] “The docker.io debian package is back to life,” 2018. [Online]. Available:https://www. collabora.com/news-and-blog/blog/2018/07/04/docker-io-debian-package-back-to-life/ ?fbclid=IwAR0KVTUsTyTFTQHqmmMzj93Vz0-qDx1WcEjiHnUqNe8lmJferwIONI0Ilwo
[26] “Create a swarm,” 2019. [Online]. Available:
https://docs.docker.com/v17.12/engine/swarm/swarm-tutorial/create-swarm/
[27] “Install and deploy kubernetes on ubuntu 18.04 lts,” 2018. [Online]. Available:
https://vitux.com/install-and-deploy-kubernetes-on-ubuntu/
[28] “How to install kubernetes on ubuntu 18.04 bionic beaver linux,” 2018. [Online]. Available:
https://linuxconfig.org/how-to-install-kubernetes-on-ubuntu-18-04-bionic-beaver-linux
[29] “Install and configure kubernetes (k8s) 1.13 on ubuntu 18.04 lts / ubuntu 18.10,” 2019. [Online]. Available:
https://www.linuxtechi.com/install-configure-kubernetes-ubuntu-18-04-ubuntu-18-10/
[30] “Dockerizing a node.js web app.” [Online]. Available:
![Figur 5: Skillnader mellan Docker Swarm och Kubernetes [17].](https://thumb-eu.123doks.com/thumbv2/5dokorg/4689975.122979/12.892.251.644.467.594/figur-skillnader-docker-swarm-kubernetes.webp)
