Parimad Kubernetes'i praktikad. Väikeste konteinerite loomine

Esimene samm Kubernetes'is juurutamisel on teie rakenduse paigutamine konteinerisse. Selles sarjas vaatleme, kuidas luua väikese ja turvalise konteineri pilti.
Dockeri abil pole konteineri piltide loomine kunagi olnud nii lihtne. Määrake põhijoon ja lisage oma muudatused ning looge konteiner.

Kuid kuigi see meetod sobib suurepäraselt alustamiseks, võivad vaikesed põhifotod tuua kaasa suurte haavatavate piltide kasutamise, mis on täis turvaprobleeme.

Enamik Docker'i pilte kasutavad peamiseks pildiks Debianit või Ubuntu't, ja kuigi see tagab suurepärase ühilduvuse ja lihtsa kohandamise (Docker'i fail vajab ainult kahte koodirida), võivad põhifotod lisada teie konteinerisse sadu megabaite täiendavat koormust. Näiteks lihtne node.js rakenduse Go fail "hello-world" kaalub umbes 700 megabaiti, samas kui teie rakenduse suurus on vaid paar megabaiti.

Seega on kogu see täiendav koormus digitaalruumi raiskamine ning suurepärane peidukoht haavatavuste ja turvaküsimuste jaoks. Seetõttu vaatame kaht viisi konteineri pildi suuruse vähendamiseks.

Esimene on väikese suurusega põhifotode kasutamine, teine on Builder Patterni kujunduspahenduse kasutamine. Väiksemate põhifotode kasutamine on tõenäoliselt kõige lihtsam viis teie konteineri suuruse vähendamiseks. Tõenäoliselt pakub teie kasutatav keel või virn rakenduse originaalpildi, mis on palju väiksem kui vaikepilt. Vaatame meie node.js konteinerit.

Vaikimisi on Dockeri baasimage'i node:8 suurus 670 MB ja image'i node:8-alpine suurus vaid 65 MB, mis on kümme korda väiksem. Kasutades väiksemat Alpine'i baasimage'i, vähendate oluliselt oma konteineri suurust. Alpine on väike ja kerge Linuxi distributsioon, mis on Dockeri kasutajate seas väga populaarne, kuna see on ühilduv paljude rakendustega, säilitades samas konteinerite väikese suuruse. Erinevalt tavalistest Dockeri image'itest

Et minna väiksemale baasimage'ile, värskendage lihtsalt Dockeri faili, et alustada uue baasimage'iga:

Nüüd, erinevalt vanast onbuild image'ist, peate oma koodi konteinerisse kopeerima ja kõik sõltuvused installima. Uus Dockeri fail algab image'iga node:alpine, seejärel loob koodile katalooge, installib sõltuvused NPM-i pakettihalduri abil ja lõpuks käivitab server.js.

Selle uuenduse abil saadakse kümme korda väiksema suurusega konteiner. Kui teie programmeerimiskeel või tehnoloogia ei toeta baasimage'i vähendamise funktsiooni, kasutage Alpine Linuxi. See annab ka võimaluse täielikult hallata konteineri sisu. Väikese suurusega baasimage'ide kasutamine on suurepärane viis väikeste konteinerite kiireks loomiseks. Kuid veelgi suurema vähendamise saavutamiseks võib kasutada Builder Pattern'i.

Tõlgitud keeltes edastatakse lähtekood kõigepealt tõlkijale ja seejärel tõeliselt käivitatakse. Kompileeritavatest keeltest muudetakse lähtekood esmalt kompileeritud koodiks. Samas kasutab kompileerimine sageli tööriistu, mida tegelikult koodi käivitamiseks ei vajata. See tähendab, et saate need tööriistad lõplikust konteinerist täielikult eemaldada. Selleks võib kasutada Builder Pattern'it.

Kood luuakse esimeses konteineris ja kompileeritakse. Seejärel pakitakse kompileeritud kood lõplikku konteinerisse ilma kompilaatorite ja tööriistadeta, mis on vajalikud selle koodi kompileerimiseks. Vaatame seda protsessi läbi Go rakenduse. Esiteks, liigume onbuild image'ilt Alpine Linuxile.

Uues Docker-failis algab konteiner pildist golang:alpine. Seejärel loob ta katalooge koodi jaoks, kopeerib sinna lähtekoodi, ehitab selle ja käivitab rakenduse. See konteiner on oluliselt väiksem kui onbuild konteiner, kuid see sisaldab siiski kompilaatorit ja teisi Go tööriistu, mis meid tegelikult ei huvita. Seega laseme lihtsalt kompileeritud programmi välja ja pakime selle enda konteinerisse.

Võite märgata midagi kummalist selles Docker-failis: see sisaldab kahte FROM rida. Esimene neljast reast näeb välja just nagu eelmine Docker-fail, välja arvatud see, et see kasutab märksõna AS, et nimetada seda etappi. Järgmises osas on uus FROM rida, mis võimaldab alustada uut pilti, kasutades alusena mitte golang:alpine, vaid Raw alpine.

Raw Alpine Linuxil ei ole peale installitud SSL-sertifikaate, mis toob kaasa enamikus API-ühendustes HTTPS-protokolli tõrke, seega laseme installida mõned juure CA-sertifikaadid.

Ja nüüd kõige huvitavam: kompileeritud koodi kopeerimiseks esimesest konteinerist teise võime lihtsalt kasutada COpy käsku, mis asub teises jaotises 5. reas. See kopeerib ainult ühe rakenduse faili ega puuduta Go tööriistu. Uus mitmeastmeline Docker-fail sisaldab konteineri pilti, mille suurus on vaid 12 megabaiti, kuigi algse konteineri pilt oli 700 megabaiti, mis on suur vahe!
Seega on väikeste aluskujutiste ja Builder Pattern'i kasutamine suurepärased viisid konteinerite loomiseks, mille suurus on oluliselt väiksem ilma palju vaeva nägemata.
Võib-olla sõltuvalt rakenduse tehnoloogiapakist on ka täiendavaid viise, kuidas pilti ja konteineri suurust vähendada, kuid kas tõeliselt väikesed konteinerid pakuvad mõõdetavat eelist? Vaadakem kaht aspekti, kus väikesed konteinerid on äärmiselt tõhusad – need on jõudlus ja turvalisus.

Selleks, et hinnata jõudluse kasvu, vaatleme konteineri loomise, selle registrisse panemise (push) ja sealt eemaldamise (pull) protsessi kestvust. Näete, et väiksema suurusega konteineril on ilmne eelis suurema konteineri ees.

Docker teeb kihtide vahemällu salvestamise, seega järgnevate kogumiste tegemine toimub väga kiiresti. Kuid paljudes CI-süsteemides, mida kasutatakse konteinerite kogumiseks ja testimiseks, kihte ei vahemälustata, mis tähendab, et siin on märkimisväärne aja kokkuhoid. Nagu näete, kestab suure konteineri koostamise aeg sõltuvalt teie masina võimsusest 34 kuni 54 sekundit, samas kui väiksemate konteinerite kasutamisel, mis on vähendatud Builder Patterniga, kestab see 23 kuni 28 sekundit. Sellise tüüpi operatsioonide korral on jõudluse kasvu määr 40-50%. Niisiis, mõelge lihtsalt, kui tihti te oma koodi loote ja testite.

Pärast konteineri koostamist peate konteineri pildi (push container image) konteineriregistrisse panema, et saaksite seda hiljem kasutada oma Kubernetes'i klastris. Soovitan kasutada Google'i konteineriregistrit.

Kasutades Google Container Registry (GCR), maksate ainult „toore“ salvestuse ja võrgu eest, lisatasu konteinerite haldamise eest ei küsita. See on konfidentsiaalne, turvaline ja väga kiire. GCR kasutab paljusid nippe, et kiirendada pull-operatsiooni. Nagu näete, kestab Docker Container Image'i pildi panemine kasutades go:onbuild olenevalt arvuti jõudlusest 15 kuni 48 sekundit, samas kui sama operatsioon väiksema konteineri puhul kestab 14 kuni 16 sekundit, kusjuures madalama jõudlusega masinate puhul suureneb kiirus kolm korda. Suuremate masinate puhul on aeg enam-vähem sama, kuna GCR kasutab globaalseid vahemälusid üldiste piltide andmebaasi jaoks, seega ei pea te neid üldse laadima. Madala jõudlusega arvutis on CPU kitsaskohaks, seega on väikeste konteinerite kasutamise eelis palju tuntavam.

Kui kasutate GCR-i, soovitan tungivalt kasutada Google Container Builderit (GCB) osana teie kogumissüsteemist.

Nagu näha, võimaldab selle kasutamine saavutada palju paremaid tulemusi Build+Push operatsiooni kestuse vähendamisel, võrreldes isegi võimsa masinaga – sellisel juhul kiireneb konteinerite koostamise ja saatmise protsess peaaegu kaks korda. Lisaks saad iga päev 120 minutit tasuta koostamist, mis enamikul juhtudel rahuldab konteinerite loomise vajadusi.

Edasi tuleb kõige olulisem jõudlusmõõdik – konteinerite tõmbamise kiirus. Ja kui sind ei huvita liiga palju push operatsiooni kestus, siis pull protsessi kestus mõjutab tõsiselt süsteemi üldist jõudlust. Oletame, et sul on kolm sõlme sisaldav klaster ja üks neist ebaõnnestub. Kui kasutad haldussüsteemi, nagu Google Kubernetes Engine, asendab see automaatselt mittetöötava sõlme uuega. Kuid see uus sõlm on täiesti tühi ning pead tõmbama kõik oma konteinerid, et see hakkaks töötama. Kui pull operatsioon kestab liiga kaua, töötab kogu selle aja su klaster madalama jõudlusega.

On palju olukordi, kus see võib juhtuda: see võib olla uue sõlme lisamine klastrisse, sõlmede värskendamine või isegi uue konteineri vahetamine juurutamiseks. Seetõttu on pull tõmbamisaega minimeerimine võtmetegur. Kindel on see, et väike konteiner laetakse alla palju kiiremini kui suur. Kui kasutad Kuberneteses mitut konteinerit, võib ajakulu olla väga märkimisväärne.

Vaata antud võrdlust: pull operatsioon väikeste konteineritega võtab sõltuvalt masina võimsusest 4-9 korda vähem aega kui sama operatsioon go:onbuild kasutamisel. Väikese suurusega jagatud aluspiltide kasutamine kiirendab oluliselt aega ja kiirus, millega uued Kuberneteses sõlmed saavad juurutada ja internetti siseneda.

Vaatame turvalisuse küsimust. Arvatakse, et väiksemad konteinerid on palju turvalisemad kui suured, kuna nende rünnakupind on väiksem. Kas see tõesti nii on? Üks Google Container Registry'i kasulikumaid funktsioone on võimalus automaatselt skaneerida teie konteinereid haavatavuste olemasolu osas. Mõni kuu tagasi lõin nii onbuild kui ka mitmeastmelisi anumaid, nii et vaatame, kas seal on mõni haavatav koht.

Tulemus on tähelepanuväärne: väikestes konteinerites leiti vaid 3 keskmist haavatavust, samas kui suurtes — 16 kriitilist ja 376 muud haavatavust. Kui vaadata suurte konteinerite sisu, on selge, et enamus turvaprobleeme ei ole seotud meie rakendusega, vaid programmidega, mida me isegi ei kasuta. Seega, kui inimesed räägivad suurest rünnakupinnast, mõtlevad nad just sellele.

Järeldus on selge: looge väikeseid konteinereid, kuna need pakuvad reaalseid eeliseid teie süsteemi jõudluses ja turvalisuses.

Kubernetes'i parimad tavad. Kubernetes'i korraldamine nimede ruumi abil

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com