De bedste Kubernetes-praksis. Oprettelse af små containere

Det første skridt i implementeringen af Kubernetes er at placere din applikation i en container. I denne serie vil vi se, hvordan man kan oprette et billede af en lille og sikker container.
Med Docker har det aldrig været nemmere at oprette containerbilleder. Angiv et grundlæggende billede, tilføj dine ændringer, og opret en container.

Selvom denne metode er god til at komme i gang, kan brugen af standard grundbilleder føre til usikker drift med store billeder, der er fyldt med sårbarheder.

Desuden bruger de fleste billeder i Docker enten Debian eller Ubuntu som grundbillede, og selvom det sikrer fremragende kompatibilitet og nem tilpasning (Docker-filen fylder kun to linjer kode), kan grundbillederne tilføje hundredvis af megabyte yderligere belastning til din container. For eksempel fylder en simpel node.js Go 'hello-world' applikation omkring 700 megabyte, mens størrelsen på selve din applikation kun er et par megabyte.

Dermed er al denne ekstra belastning en spild af digital plads og en fremragende skjulested for sårbarheder og sikkerhedsfejl. Lad os derfor se på to måder at reducere størrelsen af containerbilledet.

Den første er at bruge grundbilleder af lille størrelse, og den anden er at bruge designmønstret Builder Pattern. At bruge mindre grundbilleder er sandsynligvis den nemmeste måde at reducere størrelsen på din container. Dit sprog eller den stak, du bruger, giver sandsynligvis et grundbillede af applikationen, der er meget mindre end standardbilledet. Lad os tage et kig på vores node.js container.

Som standard er størrelsen på Docker-billedet node:8 670 MB, mens størrelsen på node:8-alpine kun er 65 MB, altså ti gange mindre. Ved at bruge det mindre Alpine-billede reducerer du betydeligt størrelsen på din container. Alpine er en lille og let Linux-distribution, der er meget populær blandt Docker-brugere, da den er kompatibel med mange applikationer, mens den stadig holder containere små. I modsætning til det standard Docker-billede "node" fjerner "node:alpine" mange hjælpefiler og programmer, og efterlader kun de filer, der er nødvendige for at køre din applikation.

For at skifte til et mindre basebillede skal du blot opdatere Docker-filen for at begynde at arbejde med det nye basebillede:

Nu, i modsætning til det gamle onbuild-billede, skal du kopiere din kode til containeren og installere eventuelle afhængigheder. I den nye Docker-fil starter containeren med billedet node:alpine, derefter oprettes der en mappe til koden, afhængighederne installeres via NPM-pakkehåndtereren, og til sidst startes server.js.

Med denne opdatering får du en container, der er ti gange mindre. Hvis dit programmeringssprog eller din stak ikke har en funktion til at reducere basebilledet, skal du bruge Alpine Linux. Det vil også give dig mulighed for helt at styre indholdet af containeren. At bruge små basebilleder er en fantastisk måde at hurtigt oprette små containere på. Men endnu mere reduktion kan opnås ved at bruge Builder Pattern.

I fortolkningsbaserede sprog overføres kildekoden først til fortolkeren, hvorefter den udføres direkte. I kompilering-sprog omdannes kildekoden på forhånd til kompileret kode. Undervejs bruger kompileringen ofte værktøjer, der faktisk ikke er nødvendige for at køre koden. Det betyder, at du kan fjerne disse værktøjer helt fra den endelige container. Det kan gøres ved hjælp af Builder Pattern.

Koden oprettes i den første container og kompileres. Derefter pakkes den kompilerede kode i den endelige container uden kompilatorer og værktøjer, der er nødvendige for at kompilere denne kode. Lad os føre en Go-applikation gennem denne proces. Først skifter vi fra onbuild-billedet til Alpine Linux.

I den nye Docker-fil starter containeren med billedet golang:alpine. Derefter opretter den en mappe til koden, kopierer den ind i kildekoden, bygger denne kildekode og kører applikationen. Denne container er meget mindre end onbuild-containeren, men den indeholder stadig kompilatoren og andre Go-værktøjer, som vi i virkeligheden ikke har brug for. Derfor lad os simpelthen udtrække den kompilerede program og pakke den ind i vores egen container.

Du kan bemærke noget mærkeligt i denne Docker-fil: den indeholder to FROM-linjer. Den første sektion på 4 linjer ser præcis ud som den foregående Docker-fil bortset fra, at den bruger nøgleordet AS til at give dette skridt et navn. I den næste sektion er der en ny FROM-linje, der gør det muligt at starte et nyt billede, hvor vi i stedet for billedet golang:alpine bruger Raw alpine som basisbillede.

Raw Alpine Linux har ingen installerede SSL-certifikater, hvilket vil føre til, at de fleste API-opkald via HTTPS mislykkes, så lad os installere nogle rod-CA-certifikater.

Og nu det mest interessante: for at kopiere den kompilerede kode fra den første container til den anden kan vi simpelthen bruge COPY-kommandoen i den 5. linje i den anden sektion. Den vil kun kopiere én applikationsfil og vil ikke berøre Go-værktøjerne. Den nye multi-stage Docker-fil vil indeholde et containerbillede, der kun fylder 12 megabyte, mens det oprindelige containerbillede var 700 megabyte, hvilket er en stor forskel!
Dermed er brugen af små basisbilleder og Builder Pattern fremragende metoder til at skabe containere i meget mindre størrelser uden meget arbejde.
Måske findes der, afhængigt af applikationens stack, flere måder at reducere størrelsen på billedet og containeren, men har små containere virkelig en målelig fordel? Lad os se på to aspekter, hvor små containere er ekstremt effektive – det er ydeevne og sikkerhed.

For assessing performance growth, let's consider the duration of the container creation process, pushing it to the registry, and subsequently pulling it from there. You can see that a smaller container has undeniable advantages over a larger container.

Docker will cache layers, so subsequent builds will run very quickly. However, in many CI systems used for building and testing containers, layers are not cached, leading to significant time savings. As you can see, the build time for a large container, depending on your machine's power, ranges from 34 to 54 seconds, while using a smaller container optimized with the Builder Pattern reduces this to 23 to 28 seconds. For such operations, the performance gain will be 40-50%. So just think about how many times you build and test your code.

Once the container is built, you need to push its image to a container registry to use it within your Kubernetes cluster. I recommend using the Google Container Registry.

By using Google Container Registry (GCR), you only pay for the raw storage and network, with no additional charges for container management. It's private, secure, and very fast. GCR employs many tricks to speed up the pull operation. As you can see, pushing a Docker Container Image using go:onbuild takes between 15 and 48 seconds, depending on your computer's performance; the same operation with a smaller container takes between 14 and 16 seconds, with the speed advantage being threefold on less powerful machines. For larger machines, the time is fairly similar, as GCR uses a global cache for the shared image repository, meaning you generally don't need to load them. In low-power computers, the CPU becomes a bottleneck, making the advantages of using small containers much more pronounced.

If you're using GCR, I highly recommend utilizing Google Container Builder (GCB) as part of your build system.

Som du kan se, muliggør brugen af dette værktøj langt bedre resultater i reduktionen af Build+Push operationens varighed end selv på en kraftfuld maskine – i dette tilfælde fremskyndes bygge- og overførselsprocessen af containere til værten næsten med det dobbelte. Desuden får du 120 minutters gratis bygge-tid hver dag, hvilket i de fleste tilfælde opfylder behovene for oprettelse af containere.

Den næste vigtigste målestok for ydeevne er udvindingshastigheden, eller download af containere (Pull). Og hvis du ikke er meget bekymret for den tid, der bruges til push-operationen, så påvirker varigheden af pull-processen alvorligt systemets samlede ydeevne. Antag, at du har et klynge bestående af tre noder, og en af dem fejler. Hvis du bruger et administrationssystem, som f.eks. Google Kubernetes Engine, vil det automatisk erstatte den ikke-fungerende node med en ny. Men denne nye node vil være helt tom, og du skal overføre alle dine containere til den for at få den til at fungere. Hvis pull-operationen tager lang tid, vil din klynge køre med nedsat ydeevne hele den tid.

Der er mange situationer, hvor dette kan ske: det kan være tilføjelsen af en ny node til klyngen, opdatering af noderne eller endda skift til en ny container til udrulning. Derfor bliver minimering af pull-udvindingsprocessens tid en afgørende faktor. Ubestridelig er det, at en lille container downloader betydeligt hurtigere end en stor. Hvis du bruger flere containere i en Kubernetes-klynge, kan tidsbesparelsen være meget betydelig.

Se på den medfølgende sammenligning: pull-operationen med små containere tager mellem 4-9 gange kortere tid afhængigt af maskinens ydeevne, end den samme operation der bruger go:onbuild. Brug af fælles basisbilleder af små containere accelererer markant den tid og hastighed, hvormed nye Kubernetes-noder kan udrulles og komme online.

Lad os se på spørgsmålet om sikkerhed. Det anses for, at mindre containere er meget mere sikre end store, fordi de har en mindre overflade at angribe. Er det egentlig tilfældet? En af de mest nyttige funktioner ved Google Container Registry er muligheden for automatisk at scanne dine containere for sårbarheder. For et par måneder siden oprettede jeg både onbuild- og multi-stage containere, lad os derfor se, om der er nogle sårbare punkter.

Resultatet er imponerende: i den lille container blev der fundet kun 3 moderate sårbarheder, mens der i den store var 16 kritiske og 376 andre sårbarheder. Hvis vi ser på indholdet af den store container, kan vi se, at de fleste sikkerhedsproblemer ikke har noget at gøre med vores applikation, men relaterer sig til programmer, som vi slet ikke bruger. Så når folk taler om en stor angrebsoverflade, er det præcis det, de mener.

Konklusionen er klar: skab små containere, for de giver reelle fordele for ydeevnen og sikkerheden i dit system.

De bedste Kubernetes-praksis. Organisering af Kubernetes med navnerum

Lidt reklame 🙂

Tak fordi du bliver hos os. Kan du lide vores artikler? Ønsker du at se flere interessante materialer? Støt os ved at bestille eller anbefale os til dine bekendte, cloud VPS til udviklere fra 4,99 $, en unik analog til entry-level servere, som vi har designet til dig: Alt om VPS (KVM) E5-2697 v3 (6 kerner) 10 GB DDR4 480 GB SSD 1 Gbps fra 19 $ eller hvordan man deler serveren korrekt? (tilgængelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).

Dell R730xd til halv pris i datacenteret Equinix Tier IV i Amsterdam? Kun hos os 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB fra 199 $ i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $! Læs om hvordan man bygger enterprise-infrastruktur ved hjælp af Dell R730xd E5-2650 v4 servere til 9000 euro for en brøkdel af prisen?

Kilde: habr.com