Docker och Kubernetes är två av de primära teknikerna i containeriseringsvärlden, men tävlar de om samma mål? Inte riktigt. Den här artikeln förklarar Vad är containerisering och hur Docker och Kubernetes kan komplettera varandra. Vidare förklarar vi också fördelarna med containerisering och orkestreringsteknik.
Containerization gör det möjligt för utvecklare att paketera programkod och dess komponenter som krävs för att köra (t.ex. ramverk, bibliotek och andra beroenden) i en enda isolerad behållare. Därför kan all programvara eller applikation i en container enkelt flyttas och användas i distinkta infrastrukturer, oavsett infrastrukturens operativsystem eller miljö.
Behållare tillåter programvarukod att vara mer bärbar (kan enkelt flyttas över plattformar och infrastrukturer) och säkramed tanke på att det tillåter utvecklare för att bygga och distribuera applikationer som är konsekventa över olika operativsystem. Tänk dock på att inte all mjukvarukod kan utformas i en mikrotjänstarkitektur. d.v.s. intensiv UI-applikationsvirtualisering görs snarare på ett annat lager av hypervisorn med Vagrant och andra.
Före containrar, utvecklare används för att skapa kod i en viss datormiljö. När de ville överföra den till en ny plats (till exempel från Linux till Windows), skulle koden vara mycket hög benägen för buggar och andra fel. Detta var en stor fråga som containrar ger en lösning på eftersom de abstrahera programkoden bort från värdoperativsystemet, gör det självständig och kan snabbt kör var som helst utan att oroa sig för buggar eller andra problem.
Kort sagt, tack vare behållare kan applikationer inkapslas i oberoende miljöer, och primära fördelar är: skalbarhet, snabbare driftsättning och närmare kongruitet mellan miljöer. Inte alla använder containrar, men siffrorna har visat ökänd tillväxt genom åren.
”Rapporten fann att 60% av backend-utvecklarna runt om i världen nu använder containrar. Jämfört med andra kvartalet 2019 har användningen av containrar ökat i genomsnitt med 10 procentenheter (pp). (Tillståndet för molnbaserad utveckling, 2020)
Begreppet containerisering i sig är inte nyligen. Ändå uppstod det med den första utgåvan av Docker 2013 som en öppen källkodsteknik, som fortfarande har en klar fördel på containeriseringsmarknaden, med 82,39% av dess andel. Faktum är att Linux redan före 2013 tillhandahöll containerteknik (Linux Containers eller LXC). Ändå hävdade Docker snabbt tronen som nummer ett och blev standardcontainerformatet.
Docker är en allmänt känd containeriseringsplattform brukade utveckla, skeppa och köra varje applikation som en bärbar och självförsörjande behållare. Den kan köras praktiskt taget var som helst, från stationära datorer till molnmiljöer och datacenter.
Vidare har Docker genom åren utvecklat många verktyg för att tillhandahålla en ”fullt utrustad” plattform för allt relaterat till containerisering. Ändå betyder det inte att alla deras verktyg är den viktigaste lösningen, med tanke på den hårda konkurrensen och kvalitetstekniken som utvecklats inom området.
Ett av de viktigaste verktygen är Docker-motor, en runtime-miljö som gör det möjligt för utvecklare att skapa och köra containrar på vilken utvecklingsmaskin som helst. För att köra en Docker-behållare kan man välja att börja med Docker-fil, vilket är en fil som uttryckligen fastställer allt som krävs för att köra Docker-avbildningen (t.ex. operativsystemets nätverksspecifikationer och filplatser).
I sin tur, Docker-bild är en bärbar statisk komponent som kan köras på Docker Engine. När behållarna är byggda och redo att köras överallt kan utvecklare lagra eller dela behållarbilden genom containerregister.
Men bara för att klargöra krävs det inte nödvändigtvis att ha Dockerfile för att köra en behållare. Istället, utvecklare kan först slå upp containerregister (Såsom DockerHub och Azure-behållarregistret) och dra befintliga bilder från containerregister, vilket sparar mycket tid och arbete. Vanligtvis innehåller dessa register ett stort antal bilder som skapats offentligt. Därför - och det här är nyckelhämtning - För att köra en Docker-behållare kan man helt enkelt hämta en bild från ett offentligt containerregister, eller anpassa bilder med en Dockerfile.
Som vi kan förstå tillhandahåller Docker en öppen källkodslösning för att packa och distribuera containeriserade applikationer. Men när antalet behållare växer, gör det också komplexiteten i att hantera dem. Således är det viktigt att säkerställa ett par aspekter (som faller in i vissa orkestreringsuppgifter), nämligen:
För att hantera dessa och andra komplexiteter har Docker utvecklat Dockersvärm, en containerorkestreringsteknik. För att vara mer exakt är detta (Docker Swarm) Dockers teknik som vanligtvis jämförs med Kubernetes, inte hela Docker-plattformen själv.
Faktiskt, Docker är standard och underliggande teknik för Kubernetes, som inbyggt använder Docker som sin körtid och drar bilder på samma sätt som utvecklare skulle göra manuellt, det vill säga med ett Docker-kommando. Ändå stöder Kubernetes också andra alternativ till Docker.
Som du kanske har gissat från föregående stycke, Kubernetes är en containerorkestreringsteknik (t.ex. OpenShift eller ECS), och Google introducerade det 2014, ett år efter Dockers release. Numera styrs det av CNCF (Cloud Native Computing Foundation).
Kubernetes utvecklades för att hjälpa användare schemalägga, hantera, automatisera driftsättning och skala containeriserade applikationer. Det är en teknik som hanterar containerisering och respektive arbetsbelastningar genom att hantera komplexiteten med att effektivt hantera ett stort antal containrar över olika servrar.
I den meningen tillhandahåller Kubernetes ett API med öppen källkod som reglerar hur och var containrar körs. I denna teknik grupperas behållare i kapslar, den grundläggande operativa enheten för Kubernetes. När containrar och pods har grupperats kan de enkelt skalas till ett annat tillstånd, och utvecklare kan styra deras livscykel.
Därför möjliggör Kubernetes orkestrering av virtuella maskiner (VM) och gör det möjligt för utvecklare att schemalägga containrar för att köras på dessa virtuella datorer, enligt deras beräkningsresurser och kraven för varje behållare. Mycket enkelt uttryckt, när utvecklare behöver släppa kod, anger de helt enkelt vilket kluster som krävs för att uppdatera, och plattformen hanterar anslutningshanteringen.
Dessutom, Kubernetes stöder ett stort antal containeriseringsverktyg, inklusive Docker, vilket leder oss till nästa ämne.
Som sagt, om vi vill jämföra Docker mot KubernetesDå skulle en rättvisare jämförelse vara mellan Docker Swarm och Kubernetes, som båda är containerorkestreringstekniker. Sanningen ska sägas kan Docker leda marknadsandelen inom containerisering, men det är inte lika framgångsrikt om vi tittar på orkestreringstekniken. Kubernetes är mer omfattande och ledande i det loppet, med 80,9k stjärnor på Github jämfört med Docker Swarm 5,8 k stjärnor.
Docker själv och Kubernetes är verkligen Kompletterande teknik. Även om båda har liknande roller, de är faktiskt väldigt olika och kan fungera perfekt tillsammans. Som det nu är klart är Docker en av de viktigaste underliggande teknologierna för Kubernetes, som i sin tur helt kan hantera containrarna som instanseras av Docker genom ett kontrollplan.
Dessutom innehåller Kubernetes många funktioner som är fördelaktiga vid hantering av containerorkestrering, till exempel lastbalansering, säkerhet, nätverk, en inbyggd isoleringsmekanism, självläkning och förmågan att skala över alla noder som körs på de inbyggda behållarna.
Vi måste förstå hur användbara båda är för att få ut det mesta av kombinationen mellan Docker och Kubernetes. Enligt rapporten från 2020 om ”Tillståndet för molnbaserad utveckling”, trots behållarnas popularitet använder inte alla faktiskt orkestreringstekniker för att hantera dem, och anledningen till det ligger i det faktum att inte alla behöver dem, särskilt när man arbetar med små applikationer och ett lågt och kontrollerbart antal containrar.
För att vara mer exakt, när programvarubehoven växer, måste de nödvändiga applikationerna också skalas vid containerisering. För att verkligen dra nytta av mikrotjänstarkitekturen, Alla krav måste vara på plats. Annars, istället för en fördel, blir containerisering en annan skuld i teknikstacken.
Därför att använda Kubernetes eller liknande verktyg är inte obligatoriskt; Det rekommenderas dock starkt för infrastrukturer som vill skala och som måste hantera ett mycket stort antal containrar över distribuerade system. Enligt rapporten för 2020 ”Containrar i företaget - Snabbt företagsantag fortsätter” utförd av IBM Market Development & Insights, endast 15% av de svarande Använd aldrig behållare utan orkestreringslösningar.
Vidare, enligt respondenterna, är dessa främsta fördelarna med att använda orkestreringslösningar:
Som meddelats den Kubernetes 1.20-utgåva,”Docker-stöd i kubelet är nu föråldrat och kommer att tas bort i en framtida utgåva.”. Ursprungligen orsakade detta lite panik eftersom många utvecklare trodde att detta skulle vara slutet på Docker och följaktligen slutet på den stora kombinationen av Docker och Kubernetes. Lyckligtvis lanserade Kubernetes den 2 december 2020 ett blogginlägg som klargjorde att ”Det är inte så dramatiskt som det låter”.
Som de förklarar, inuti ett Kubernetes-kluster, finns det en sak som heter ”containerkörning” som används för att dra och köra containeravbildningarna. Docker är det mest populära alternativet för den körtiden, och problemet är det den var inte utformad för att vara inbäddad i Kubernetes.
Behållarens körtid är gjord för att vara människovänlig - vilket gör Docker ännu större. För människor. - men inte särskilt lämplig för en programvara som Kubernetes. Följaktligen måste Kubernetes använda Dockershim för att få vad den verkligen behöver och är containerd. Detta är långt ifrån den perfekta lösningen för Kubernetes eftersom det är en extra teknik som de behöver underhålla och hantera.
Sammanfattningsvis, vad tillkännagivandet verkligen säger är att Dockershim tas bort från Kubelet, tar bort stöd för Docker som en containerkörning. Detta innebär att bilder producerade av Docker fortsätter att fungera i en utvecklares Kubernetes-kluster, som vanligt.
Även om det inte nödvändigtvis är det bästa tillvägagångssättet för varje arbetsbelastning eller applikation, fördelarna med containerisering har fångat uppmärksamheten hos många utvecklare och företag. Några av de främsta fördelarna inkluderar förbättrad applikationskvalitet, förbättrad produktivitet, minskad driftstopp och snabbare respons på ändringar.
Men hur kan Dockers och Kubernetes arbeta tillsammans för att få ut det mesta av containerisering?
Å ena sidan Hamnarbetare gör det möjligt för utvecklare att paketera sina applikationer i isolerade behållare via kommandoraden. Efteråt kan dessa applikationer köras över utvecklarnas IT-miljöer.
Å andra sidan Kubernetes erbjuder en orkestreringslösning som schemalägger och automatiserar containeriseringsuppgifter, till exempel hantering, skalning, distribution och nätverk under programmets livscykel.
Därför Docker och Kubernetes kan - och borde ofta - komplettera varandra. Genom att kombinera dessa tekniker med DevOps-praxis kan tillhandahålla en baslinje för mikrotjänstarkitektur som möjliggör snabb leverans samt skalbarhet för molnbaserade applikationer.
Marknadsföringspraktikant med särskilt intresse för teknik och forskning. På min fritid spelar jag volleyboll och skämmer bort min hund så mycket som möjligt.
Säkerhets- och molnverksamhetsexpert. Bakgrund inom kollektivtrafik, Finans, och regering. Handlar vanligtvis mynt på decentraliserade börser:)
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
