Docker og Kubernetes er to af de primære teknologier i containeriseringsverdenen, men konkurrerer de om det samme mål? Ikke rigtig. Denne artikel forklarer Hvad er containerisering og hvordan Docker og Kubernetes kan supplere hinanden. Yderligere forklarer vi også fordelene ved containerisering og orkestreringsteknologier.
Containerization gør det muligt for udviklere at pakke softwarekode og dens nødvendige komponenter til at køre (f.eks. Rammer, biblioteker og andre afhængigheder) i en enkelt isoleret beholder. Derfor kan enhver software eller applikation i en container let flyttes og bruges i forskellige infrastrukturer, uanset infrastrukturens operativsystem eller miljø.
Containere tillader softwarekode at være mere transportabel (kan let flyttes på tværs af platforme og infrastrukturer) og sikkeri betragtning af at det tillader udviklere til at opbygge og implementere applikationer, der er konsistente på tværs af forskellige operativsystemer. Husk dog, at ikke al softwarekode kan designes i en mikroservicearkitektur. dvs. intens UI-applikationsvirtualisering udføres snarere på et andet lag af hypervisoren med Vagrant og andre.
Før containere, udviklere bruges til at oprette kode i et bestemt computermiljø. Når de ønskede at overføre det til et nyt sted (for eksempel fra Linux til Windows), ville koden være meget høj tilbøjelige til fejl og andre fejl. Dette var et stort problem, som containere giver en løsning på, da de abstrahere softwarekoden væk fra værtsoperativsystemet, gør det uafhængig og i stand til hurtigt Kør hvor som helst uden at bekymre sig om fejl eller andre problemer.
Kort sagt, takket være containere kan applikationer blive indkapslet i uafhængige miljøer, og primære fordele er: skalerbarhed, hurtigere implementering og tættere kongruitet mellem miljøer. Ikke alle bruger containere, men tallene har vist berygtet vækst gennem årene.
„Rapporten fandt ud af, at 60% af backend-udviklere rundt om i verden nu bruger containere. Sammenlignet med 2. kvartal 2019 har der i gennemsnit været en stigning på 10 procentpoint (pp) i brugen af containere. (State of Cloud Native Development, 2020)
Begrebet containerisering i sig selv er ikke nyligt. Alligevel opstod det med den første udgivelse af Docker i 2013 som en open source-teknologi, som stadig har en klar fordel på containeriseringsmarkedet, idet 82,39% af sin andel. Faktisk leverede Linux allerede containerteknologier (Linux Containers eller LXC) før 2013. Alligevel hævdede Docker hurtigt tronen som nummer et og blev standardcontainerformatet.
Docker er en meget kendt containeriseringsplatform vant til udvikle, sende og køre enhver anvendelse som en bærbar og selvforsynende beholder. Det kan køre stort set hvor som helst fra desktops til cloud-miljøer og datacentre.
Desuden har Docker gennem årene udviklet adskillige værktøjer til at levere en „fuldt udstyret“ platform til alt relateret til containerisering. Alligevel betyder det ikke, at alle deres værktøjer er den vigtigste go-to-løsning i betragtning af den hårde konkurrence og kvalitetsteknologier, der er udviklet på området.
Et af de primære værktøjer er Docker-motor, et runtime-miljø, der gør det muligt for udviklere at oprette og køre containere på enhver udviklingsmaskine. For at køre en Docker-container kan man vælge at starte med Docker fil, som er en fil, der eksplicit etablerer alt, hvad der kræves for at køre Docker-billedet (f.eks. OS-netværksspecifikationerne og filplaceringerne).
Til gengæld Docker-billede er en bærbar statisk komponent, der kan køres på Docker Engine. Når containerne er bygget og klar til at køre overalt, kan udviklere gemme eller dele containerbilledet gennem containerregistre.
Men bare for at præcisere er det ikke nødvendigvis nødvendigt at have Dockerfile til at køre en container. I stedet, udviklere kan først slå containerregistre op (såsom DockerHub og Azure Container Registry) og træk eksisterende billeder fra containerregistre, hvilket sparer meget tid og arbejde. Typisk inkluderer disse registre et massivt antal billeder oprettet offentligt. Derfor - og dette er nøgle takeaway - For at køre en Docker-container kan man simpelthen trække et billede fra et offentligt containerregister eller tilpasse billeder ved hjælp af en Dockerfile.
Som vi kan opfatte, leverer Docker en open source-løsning til at pakke og distribuere containeriserede applikationer. Men efterhånden som antallet af containere vokser, vokser det også kompleksiteten ved at styre dem. Det er således vigtigt at sikre et par aspekter (som falder ind under nogle orkestreringsopgaver), nemlig:
For at håndtere disse og andre kompleksiteter har Docker udviklet Docker Swarm, en containerorkestreringsteknologi. For at være mere præcis er dette (Docker Swarm) Dockers teknologi, der normalt sammenlignes med Kubernetes, ikke hele Docker-platformen selv.
Faktisk, Docker er standard og underliggende teknologi til Kubernetes, som oprindeligt bruger Docker som runtime og trækker billeder på samme måde, som udviklere ville gøre manuelt, det vil sige ved hjælp af en Docker-kommando. Ikke desto mindre understøtter Kubernetes også andre alternativer til Docker.
Som du måske har gættet fra forrige afsnit, Kubernetes er en containerorkestreringsteknologi (f.eks. Som OpenShift eller ECS), og Google introducerede det i 2014, et år efter Dockers udgivelse. I dag styres det af CNCF (Cloud Native Computing Foundation).
Kubernetes blev udviklet til at hjælpe brugere planlægge, administrere, automatisere udrulning og skalere containeriserede applikationer. Det er en teknologi, der håndterer containerisering og respektive arbejdsbelastninger ved at tackle kompleksiteten ved effektivt at håndtere et omfattende antal containere på tværs af forskellige servere.
I den forstand leverer Kubernetes en open source API, der regulerer, hvordan og hvor containere kører. I denne teknologi er containere grupperet i kapsler, den grundlæggende operationelle enhed for Kubernetes. Når containere og pods er grupperet, kan de nemt skaleres til en anden tilstand, og udviklere kan styre deres livscyklus.
Derfor muliggør Kubernetes orkestrering af virtuelle maskiner (VM'er) og giver udviklere mulighed for at planlægge containere til at køre på disse VM'er i henhold til deres beregningsressourcer og kravene til hver container. Meget enkelt sagt, når udviklere har brug for at frigive kode, angiver de simpelthen, hvilken klynge der skal opdateres, og platformen håndterer forbindelsesstyringen.
Desuden Kubernetes understøtter et stort antal containeriseringsværktøjer, inklusive Docker, som fører os til det næste emne.
Som nævnt, hvis vi ville sammenligne Docker mod KubernetesEn mere retfærdig sammenligning ville være mellem Docker Swarm og Kubernetes, som begge er containerorkestreringsteknologier. Sandheden skal siges, Docker kan føre markedsandelen inden for containerisering, men det er ikke så vellykket, hvis vi ser på orkestreringsteknologien. Kubernetes er mere omfattende og leder i det løb, der har 80,9k stjerner på Github sammenlignet med Docker Swarms 5,8 km stjerner.
Docker selv og Kubernetes er faktisk komplementære teknologier. Selvom begge har lignende roller, er de faktisk meget forskellige og kan arbejde perfekt sammen. Som det nu er klart, er Docker en af de vigtigste underliggende teknologier i Kubernetes, som igen er i stand til fuldstændigt at styre containerne instanceret af Docker gennem et kontrolplan.
Desuden indeholder Kubernetes adskillige funktioner, der er fordelagtige ved håndtering af containerorkestrering, såsom belastningsbalancering, sikkerhed, netværk, en indbygget isolationsmekanisme, selvhelbredelse og evnen til at skalere på tværs af alle de noder, der kører på de indbyggede containere.
Vi er nødt til at forstå, hvor nyttige begge er for at få mest muligt ud af kombinationen mellem Docker og Kubernetes. I henhold til 2020-rapporten om „Status for cloud-native udvikling“På trods af populariteten af containere bruger ikke alle faktisk orkestreringsteknologier til at styre dem, og årsagen til det ligger i det faktum, at ikke alle har brug for dem, især når man arbejder med små applikationer og et lavt og kontrollerbart antal containere.
For at være mere præcis, efterhånden som softwarebehovene vokser, skal de nødvendige applikationer også skaleres ved containerisering. Således for virkelig at drage fordel af mikroservicearkitektur, Alle krav skal være på plads. Ellers bliver containerisering i stedet for en fordel en anden forpligtelse i tech-stakken.
Derfor brug af Kubernetes eller et lignende værktøj er ikke obligatorisk; det anbefales dog stærkt til infrastrukturer, der ønsker at skalere, og som skal håndtere et meget stort antal containere på tværs af distribuerede systemer. I henhold til 2020-rapporten „Containere i virksomheden - Hurtig virksomhedsadoption fortsætter“ udført af IBM Market Development & Insights, kun 15% af respondenterne Brug aldrig containere uden orkestreringsløsninger.
Ifølge respondenterne er disse endvidere de største fordele ved at bruge orkestreringsløsninger:
Som annonceret den Kubernetes 1.20 udgivelse,“Docker-understøttelse i kubelet er nu forældet og vil blive fjernet i en fremtidig udgivelse.„. Oprindeligt forårsagede dette lidt panik, da mange udviklere troede, at dette ville være slutningen på Docker og følgelig slutningen på den store kombination af Docker plus Kubernetes. Heldigvis lancerede Kubernetes den 2. december 2020 et blogindlæg, der præciserede, at“Det er ikke så dramatisk, som det lyder„.
Som de forklarer, er der inde i en Kubernetes-klynge en ting, der hedder 'container runtime“, der bruges til at trække og køre containerbillederne. Docker er den mest populære mulighed for den runtime, og problemet er det det var ikke designet til at blive indlejret i Kubernetes.
Beholderens runtime er lavet til at være menneskevenlig - hvilket gør Docker endnu større. For mennesker. - men ikke særlig velegnet til en software som Kubernetes. Derfor skal Kubernetes bruge Dockershim for at få det, det virkelig har brug for og er containeret. Dette er langt fra den ideelle løsning for Kubernetes, fordi det er en ekstra teknologi, som de har brug for at vedligeholde og håndtere.
Afslutningsvis, hvad meddelelsen virkelig siger, er, at Dockershim fjernes fra Kubelet, fjerner understøttelse af Docker som en container runtime. Det betyder, at billeder produceret af Docker vil fortsætte med at arbejde i en udviklers Kubernetes-klynge, som sædvanligt.
Selvom det ikke nødvendigvis er den bedste tilgang til enhver arbejdsbyrde eller applikation, fordelene ved containerisering har fanget opmærksomheden fra mange udviklere og virksomheder. Nogle af de største fordele omfatter forbedret applikationskvalitet, forbedret produktivitet, reduceret applikationsnedetid og hurtigere respons på ændringer.
Men hvordan kan Dockers og Kubernetes arbejde sammen for at få mest muligt ud af containerisering?
På den ene side havnearbejder gør det muligt for udviklere at pakke deres applikationer i isolerede containere gennem kommandolinjen. Bagefter er disse applikationer i stand til at køre på tværs af udviklernes it-miljøer.
På den anden side Kubernetes tilbyder en orkestreringsløsning, der planlægger og automatiserer containeriseringsopgaver, såsom administration, skalering, udrulning og netværk gennem hele programmets livscyklus.
Derfor Docker og Kubernetes kan - og bør ofte - supplere hinanden. Kombinationen af disse teknologier med DevOps-praksis kan give en basislinje for mikroservicearkitektur, der giver mulighed for hurtig levering samt skalerbarhed af cloud-native applikationer.
Marketing praktikant med særlig interesse for teknologi og forskning. I min fritid spiller jeg volleyball og forkæler min hund så meget som muligt.
Sikkerheds- og cloud-driftsekspert. Baggrund i offentlig transport, Finans, og regering. Handler normalt mønter på decentrale børser:)
People who read this post, also found these interesting:
.webp)
