{"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\/no\/blog\/administrirovanie\/kubernetes-open-source-protiv-vendorskogo","title":{"rendered":"Kubernetes: open source mot leverand\u00f8rspesifikk","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hei, jeg heter Dmitrij Krasnov. Jeg har drevet med administrasjon av Kubernetes-klynger og bygget kompliserte mikrotjenestearkitekturer i over fem \u00e5r. Tidlig i \u00e5r lanserte vi en tjeneste for styring av Kubernetes-klynger basert p\u00e5 Containerum. I den forbindelse vil jeg fortelle om hva Kubernetes egentlig er, og hvordan integrasjon med en leverand\u00f8r skiller seg fra open source.<\/b><\/p>\n

For \u00e5 begynne, hva er Kubernetes<\/a><\/noindex>? Det er et system for h\u00e5ndtering av containere p\u00e5 et stort antall verter. P\u00e5 gresk oversettes det for \u00f8vrig til \"pilot\" eller \"styrmann\". Det ble opprinnelig utviklet av Google, og deretter, som et teknologisk bidrag, overf\u00f8rt til Cloud Native Computing Foundation, en internasjonal ideell organisasjon som samler ledende utviklere, sluttbrukere og leverand\u00f8rer av containerteknologier. <\/p>\n

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

\u00c5 styre et stort antall containere <\/h3>\n

\nLa oss n\u00e5 se p\u00e5 hva disse containerne er. Det er applikasjoner sammen med alt deres milj\u00f8 \u2013 hovedsakelig bibliotekene som programmet er avhengig av. Alt dette er pakket inn i arkiver og presentert som et bilde som kan kj\u00f8res uavhengig av operativsystemet, testes og mer. Men det finnes et problem \u2014 det er veldig vanskelig \u00e5 h\u00e5ndtere containere p\u00e5 et stort antall verter. Derfor ble Kubernetes skapt. <\/p>\n

Containerbildet representerer en applikasjon pluss dens avhengigheter. Applikasjonen, dens avhengigheter og bilde av filsystemet til OS ligger i forskjellige deler av bildet, s\u00e5kalte lag. Lagene kan gjenbrukes for forskjellige containere. For eksempel kan alle applikasjoner i selskapet bruke det grunnleggende laget av Ubuntu. N\u00e5r containere startes, er det ikke behov for \u00e5 lagre mange kopier av ett og samme grunnlagslag p\u00e5 verten. Dette gj\u00f8r det mulig \u00e5 optimalisere lagringen og distribusjonen av bilder.<\/p>\n

N\u00e5r vi \u00f8nsker \u00e5 kj\u00f8re en applikasjon fra en container, legges de n\u00f8dvendige lagene opp\u00e5 hverandre og danner et overlay-filsystem. \u00d8verst legges et skrivelag, som fjernes n\u00e5r containeren stoppes. Dette sikrer at applikasjonen alltid har det samme milj\u00f8et ved oppstart, som ikke kan endres. Det garanterer reproduserbarhet av milj\u00f8et p\u00e5 ulike vertssystemer. Enten det er Ubuntu eller CentOS, vil milj\u00f8et alltid v\u00e6re det samme. I tillegg er containeren isolert fra verten ved hjelp av mekanismer innebygd i Linux-kjernen. Applikasjoner i containeren har ikke tilgang til filer, prosesser eller andre containere p\u00e5 verten. Slik isolasjon av applikasjoner fra vertssystemet gir et ekstra lag med sikkerhet. <\/p>\n

Det finnes mange verkt\u00f8y for \u00e5 administrere containere p\u00e5 verten. Det mest popul\u00e6re av dem er Docker. Det gir en full livssyklus for containerne. Imidlertid fungerer det bare p\u00e5 \u00e9n vert. N\u00e5r det er behov for \u00e5 h\u00e5ndtere containere p\u00e5 flere verter, kan Docker gj\u00f8re livet til ingeni\u00f8rer til et mareritt. Derfor ble Kubernetes utviklet.<\/p>\n

Ettersp\u00f8rselen etter Kubernetes skyldes nettopp muligheten til \u00e5 styre grupper av containere p\u00e5 flere verter som en enhet. Populariteten til systemet sikrer muligheten til \u00e5 bygge DevOps eller Development Operations, der Kubernetes brukes til \u00e5 kj\u00f8re prosessene i denne DevOps.<\/p>\n

\"Kubernetes:
\n
\nFigur 1. Schematic illustration of how Kubernetes works<\/i><\/p>\n

Full automatisering<\/h3>\n

\nDevOps representerer i prinsippet automatisering av utviklingsprosessen. Grovt sagt skriver utviklere kode som lastes opp til et repository. Deretter kan denne koden automatisk bygges direkte i en container med alle biblioteker, testes og \"rulles ut\" til neste fase \u2013 Staging, og deretter umiddelbart til Production.<\/p>\n

Sammen med Kubernetes gj\u00f8r DevOps det mulig \u00e5 automatisere denne prosessen, slik at den nesten skjer uten utviklernes involvering. Dette \u00f8ker hastigheten p\u00e5 byggingen betydelig, ettersom utvikleren ikke trenger \u00e5 gj\u00f8re dette p\u00e5 sin egen datamaskin \u2014 han skriver bare en kodesnutt, pusher koden til depotet, hvoretter en pipeline settes i gang, som kan inkludere bygging, testing og distribusjon. Dette skjer for hver commit, noe som gj\u00f8r at testing skjer kontinuerlig.<\/p>\n

Bruken av containere gir ogs\u00e5 trygghet for at hele milj\u00f8et til programmet vil g\u00e5 til produksjon akkurat slik det ble testet. Det vil si at det ikke oppst\u00e5r problemer som \u00abi testen var det en versjon, i produksjon var det en annen, og n\u00e5r det ble plassert, krasjet alt\u00bb. Siden vi i dag har en trend mot mikrotjenestearkitektur, der det i stedet for ett stort program finnes hundrevis av sm\u00e5, vil det kreve et enormt antall ansatte \u00e5 administrere dem manuelt. Derfor bruker vi Kubernetes.<\/p>\n

<\/p>\n

Fordeler, fordeler, fordeler<\/h3>\n

<\/b>
\nN\u00e5r det gjelder fordelene med Kubernetes som plattform, har den betydelige fordeler n\u00e5r det gjelder administrering av mikrotjenestearkitektur. <\/p>\n