{"id":81130,"date":"2020-05-11T01:42:39","date_gmt":"2020-05-10T23:42:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kubernetes-open-source-protiv-vendorskogo"},"modified":"2020-05-11T01:42:39","modified_gmt":"2020-05-10T23:42:39","slug":"kubernetes-open-source-protiv-vendorskogo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kubernetes-open-source-protiv-vendorskogo","title":{"rendered":"Kubernetes: open source versus leverand\u00f8rspecifik","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej, jeg hedder Dmitry Krasnov. Jeg har i mere end fem \u00e5r arbejdet med administration af Kubernetes-klynger og opbygning af komplekse mikroservice-arkitekturer. I begyndelsen af dette \u00e5r lancerede vi en service til styring af Kubernetes-klynger baseret p\u00e5 Containerum. Jeg vil benytte lejligheden til at fort\u00e6lle, hvad Kubernetes egentlig er, og hvordan integrationen med en leverand\u00f8r adskiller sig fra open source.<\/b><\/p>\n

For at starte, hvad er Kubernetes<\/a><\/noindex>. Dette er et system til styring af containere p\u00e5 et stort antal v\u00e6rter. P\u00e5 gr\u00e6sk overs\u00e6ttes det for \u00f8vrigt til 'pilot' eller 'styrmand'. Oprindeligt udviklet af Google, blev det efterf\u00f8lgende givet som teknologisk bidrag til Cloud Native Computing Foundation, en international non-profit organisation, der samler f\u00f8rende globale udviklere, slutbrugere og leverand\u00f8rer af containerteknologier. <\/p>\n

\"Kubernetes:
\n<\/a><\/noindex><\/p>\n

At styre et stort antal containere <\/h3>\n

\nLad os nu se n\u00e6rmere p\u00e5, hvad disse containere egentlig er. Det er en applikation sammen med sit milj\u00f8 \u2013 prim\u00e6rt de biblioteker, som programmets funktionalitet afh\u00e6nger af. Alt dette pakkes i arkiver og pr\u00e6senteres som et billede, der kan k\u00f8res uanset operativsystemet, testes og meget mere. Men der er et problem \u2014 det er meget sv\u00e6rt at administrere containere p\u00e5 et stort antal v\u00e6rter. Derfor blev Kubernetes skabt. <\/p>\n

Containerbilledet best\u00e5r af applikationen plus dens afh\u00e6ngigheder. Applikationen, dens afh\u00e6ngigheder og filsystembilledet af OS'en er placeret i forskellige dele af billedet, de s\u00e5kaldte lag. Lagene kan genbruges til forskellige containere. For eksempel kan et grundlag som Ubuntu bruges af alle applikationer i virksomheden. N\u00e5r containere startes, er der ikke behov for at gemme mange kopier af det samme grundlag p\u00e5 v\u00e6rten. Dette optimerer lagring og levering af billeder.<\/p>\n

N\u00e5r vi \u00f8nsker at k\u00f8re en applikation fra en container, l\u00e6gges de n\u00f8dvendige lag oven p\u00e5 hinanden og danner et overlay-filsystem. Ovenp\u00e5 l\u00e6gges et skrivelag, som fjernes, n\u00e5r containeren stoppes. Dette sikrer, at applikationen altid har et ensartet milj\u00f8 ved opstart af containeren, som ikke kan \u00e6ndres. Det sikrer reproducerbarhed af milj\u00f8et p\u00e5 forskellige v\u00e6rts-OS'er. Uanset om det er Ubuntu eller CentOS, vil milj\u00f8et altid v\u00e6re det samme. Desuden er containeren isoleret fra v\u00e6rten ved hj\u00e6lp af indbyggede mekanismer i Linux-kernen. Applikationer i containeren kan ikke se filer eller processer fra v\u00e6rten eller nabocontainere. Denne isolation af applikationer fra v\u00e6rts-OS'et giver et ekstra sikkerhedslag. <\/p>\n

Der er mange v\u00e6rkt\u00f8jer til at administrere containere p\u00e5 v\u00e6rten. Det mest popul\u00e6re er Docker. Det g\u00f8r det muligt at sikre hele livscyklussen for arbejdet med containere. Men det fungerer kun p\u00e5 \u00e9n v\u00e6rt. I tilf\u00e6lde af behov for at administrere containere p\u00e5 mange v\u00e6rter kan Docker g\u00f8re livet besv\u00e6rligt for ingeni\u00f8rer. Derfor blev Kubernetes skabt.<\/p>\n

Eftersp\u00f8rgslen efter Kubernetes skyldes netop muligheden for at styre grupper af containere p\u00e5 mange v\u00e6rter som en samlet enhed. Systemets popularitet sikrer muligheden for at opbygge DevOps eller Development Operations, hvor Kubernetes bruges til at k\u00f8re processer inden for denne DevOps.<\/p>\n

\"Kubernetes:
\n
\nFigur 1. Schematic illustration of the operation principle of Kubernetes<\/i><\/p>\n

Fuld automatisering<\/h3>\n

\nDevOps repr\u00e6senterer grundl\u00e6ggende automatisering af udviklingsprocessen. Groft sagt skriver udviklerne kode, som uploades til et repository. Derefter kan denne kode automatisk samles i en container med alle biblioteker, testes, og \"udrulles\" til n\u00e6ste fase \u2013 Staging, og derefter direkte til Production.<\/p>\n

Sammen med Kubernetes muligg\u00f8r DevOps automatik af denne proces, s\u00e5 den n\u00e6sten kan finde sted uden udviklernes direkte involvering. Dette betydeligt accelererer opbygningen, da udvikleren ikke beh\u00f8ver at g\u00f8re dette p\u00e5 sin egen computer \u2014 han skriver simpelthen en kodebit, pushe koden til depotet, hvorefter en pipeline aktiveres, som kan inkludere opbygnings-, test- og udrulningsprocessen. Dette sker for hver commit, s\u00e5 testningen finder sted kontinuerligt.<\/p>\n

Brugen af containere sikrer desuden, at hele milj\u00f8et for dette program g\u00e5r i produktion pr\u00e6cis i den version, som blev testet. Det vil sige, at der ikke opst\u00e5r problemer som \"der var \u00e9n version i testen, men en anden i produktionen, og da vi deployede, gik det hele ned\". Da vi i dag har en tendens mod mikrotjenestearkitektur, hvor \u00e9t stort program erstattes af hundrede sm\u00e5, vil det kr\u00e6ve et k\u00e6mpe personale at administrere dem manuelt. Derfor bruger vi Kubernetes.<\/p>\n

<\/p>\n

Fordele, fordele, fordele<\/h3>\n

<\/b>
\nN\u00e5r vi taler om fordelene ved Kubernetes som platform, har den betydelige fordele i forhold til styring af mikrotjenestearkitektur. <\/p>\n