Kubernetesi parimad praktikad. Väikeste konteinerite loomine

Kubernetesi esmane juurutamine hõlmab teie rakenduse paigutamist konteinerisse. Selles seerias uurime, kuidas luua väikese ja turvalise konteineri pilti.
Docker'i kaudu on konteinerite piltide loomine kunagi olnud nii lihtne. Määrake aluskuju, lisage oma muudatused ja looge konteiner.

Kuigi see meetod sobib suurepäraselt alustamiseks, võib vaikimisi aluskujudega töötamine põhjustada suures suuruses piltide ebaturvalist kasutamist, mis on täis haavatavusi.

Lisaks kasutavad enamik Docker'i pilte alusena Debianit või Ubuntut, ja kuigi see tagab suurepärase ühilduvuse ja lihtsa kohandamise (Docker'i fail hõlmab vaid kahte koodirea), võivad aluskujud lisada teie konteinerisse sadu megabaite lisakoormust. Näiteks lihtne Node.js rakenduse Go 'hello-world' fail võtab umbes 700 megabaiti, samas kui teie rakenduse tegelik suurus on vaid paar megabaiti.

Seega on kogu see lisakoormus digitaalsete ruumide tarbetu kulu ja suurepärane peidupaik haavatavuste ja turvavea jaoks. Vaatame seetõttu kahte viisi, kuidas konteineri suurust vähendada.

Esiteks – kasutada väikese suurusega aluspilte, teiseks – rakendada Builder Pattern projekteerimismustrit. Väiksemate aluspiltide kasutamine on tõenäoliselt kõige lihtsam viis teie konteineri suuruse vähendamiseks. Tõenäoliselt pakub teie kasutatav keel või tehnoloogiakogum algset rakenduspilti, mis on oluliselt väiksem kui vaikimisi pilt. Vaadakem meie node.js konteinerit.

Vaikimisi on Docker'i baaspildi suurus node:8 670 MB ning node:8-alpine'i suurus vaid 65 MB, mis tähendab, et see on 10 korda väiksem. Kasutades väiksemat Alpine'i baaspilti, vähendate erhebalt oma konteineri suurust. Alpine on väike ja kerge Linuxi distributsioon, mis on Docker'i kasutajate seas väga populaarne, sest see on ühilduv paljude rakendustega ning samal ajal säilitab väikese konteineri suuruse. Erinevalt standardsetest Docker'i piltidest nagu „node”, eemaldab „node:alpine” palju teenusefaile ja programme, jättes alles vaid need, mis on vajalikud teie rakenduse käivitamiseks.

Smaller base image'e kasutamiseks värskendage lihtsalt Docker-faili, et alustada uue baaspildiga:

Nüüd, erinevalt vanast onbuild pildist, peate oma koodi konteinerisse kopeerima ja kõik sõltuvused paigaldama. Uues Docker-failis algab konteiner node:alpine pildist, seejärel loob kausta koodi, installib sõltuvused NPM-i pakihaldusega ja lõpuks käivitab server.js.

Selle uuenduse abil saab konteineri kümme korda väiksemaks. Kui teie programmeerimiskeel või tehnoloogia virn ei toeta põhipildi vähendamist, kasutage Alpine Linuxi. See annab ka täieliku kontrolli konteineri sisu üle. Väikeste põhi­piltide kasutamine on suurepärane viis väikeste konteinerite kiireks loomiseks. Kuid veelgi suuremat vähendust on võimalik saavutada, kasutades Builder Pattern'i.

Tõlgitavates keeltes edastatakse lähtekood esmalt tõlkijale ja seejärel täidetakse. Kompileeritavates keeltes muudetakse lähtekood eelnevalt kompileeritud koodiks. Samuti kasutab kompileerimine sageli tööriistu, mis ei ole koodi käivitamiseks tegelikult vajalikud. See tähendab, et saate need tööriistad finaliseerimisest täielikult eemaldada. Selleks võib kasutada Builder Pattern'i.

Kood genereeritakse esimeses konteineris ja kompileeritakse. Seejärel pakitakse kompileeritud kood lõppkonteinerisse, millel puuduvad kompilaatorid ja tööriistad, mis on vajalikud selle koodi kompileerimiseks. Vaatame nüüd seda protsessi läbi Go rakenduse. Esiteks liigume onbuild pildilt Alpine Linuxi.

Uues Docker failis algab konteiner golang:alpine pildiga. See loob seejärel katalooge koodi jaoks, kopeerib selle lähtekoodi sisse, kompileerib selle ja käivitab rakenduse. See konteiner on palju väiksem kui onbuild konteiner, kuid sisaldab endiselt kompilaatorit ja muid Go tööriistu, mis me tegelikult ei vaja. Seega, võtame lihtsalt kompileeritud programmi ja paneme selle omaenda konteinerisse.

Võite märgata midagi kummalist selles Docker-failis: sellel on kaks FROM rida. Esimene osa neljast reast näeb välja täpselt nagu eelmine Docker-fail, välja arvatud see, et see kasutab AS võtit, et sellele etapile nimi anda. Järgmises osas on uus FROM rida, mis võimaldab alustada uut pilti, kasutades põhiosana Raw alpine'i, mitte golang:alpine'i.

Raw Alpine Linuxil ei ole mingeid SSL-sertifikaate installitud, mis põhjustab enamiku API HTTPS-protokolli kõnede ebaõnnestumise, seega laseme installida mõned juure CA sertifikaadid.

Ja nüüd tuleb kõige huvitavam osa: esimesest konteinerist kompileeritud koodi kopeerimiseks teise võib lihtsalt kasutada 5. rea COPY käsku teises osas. See kopeerib ainult ühe rakenduse faili ja ei puuduta Go teenindustööriistu. Uus mitmeastmeline Docker-fail sisaldab konteineri pilti, mille suurus on vaid 12 megabaiti, samas kui algne konteineri pilt oli 700 megabaiti, ja see on suur erinevus!
Seega, väikeste baasipiltide ja Builder Pattern'i kasutamine on suurepärased viisid luua palju väiksemaid konteinerite ilma suure töökoormuseta.
Sõltuvalt rakenduste tehnoloogilisest virnast võivad olla ka täiendavad viisid pildi ja konteineri suuruse vähendamiseks, kuid kas tõesti väikestel konteineritel on mõõdetav eelis? Vaatame kahte aspekti, kus väikesed konteinerid on äärmiselt tõhusad – tootlikkus ja turvalisus.

Tootlikkuse kasvu hindamiseks vaatame konteineri loomise aega, selle registrisse sisestamise (push) ja sealt tõmbamise (pull) kestust. Näete, et väiksema suurusega konteineril on ühemõtteline eelis võrreldes suurema konteeriga.

Docker cache'ib oma kihte, seega järgmised koostamisprotsessid toimuvad väga kiiresti. Siiski paljudes CI süsteemides, mida kasutatakse konteinerite koostamiseks ja testimiseks, kihte ei cache'ita, mistõttu saavutatakse siin märkimisväärne ajasääst. Nagu näha, sõltub suure konteineri koostamisaeg teie masina võimsusest ning varieerub 34 kuni 54 sekundi vahel, samas kui Builder Pattern'i abil vähendatud konteineri koostamisaeg on 23 kuni 28 sekundi vahemikus. Selliste operatsioonide jaoks on jõudluse tõus 40-50%. Seega mõelge lihtsalt, kui mitu korda te oma koodi loote ja testite.

Pärast konteineri koostamist peate selle pildi sisestama (push container image) konteineriregistrisse, et seejärel kasutada seda oma Kubernetes klastris. Soovitan kasutada Google'i konteineriregistrit.

Kasutades Google Container Registry (GCR), maksate ainult „toore“ salvestamise ja võrgu eest, lisatasu konteinerite haldamise eest ei küsita. See on konfidentsiaalne, ohutu ja väga kiire. GCR kasutab mitmeid nippe, et pull-operatsiooni kiirendada. Nagu näete, pildi sisestamine Docker Container Image kasutades go:onbuild sõltuvalt arvuti jõudlusest võtab aega 15 kuni 48 sekundit, samas kui sama operatsioon väiksema konteineriga – 14 kuni 16 sekundit, kusjuures vähem jõuliste masinate jaoks suureneb operatsiooni kiirus kolm korda. Suurte masinate puhul on aeg enam-vähem sama, kuna GCR kasutab globaalset vahemälu, et jagada pilte, seega ei pea te neid üldse laadima. Madala jõudlusega arvutis on CPU kitsaskohaks, seega on väikeste konteinerite kasutamise eelised siin palju tuntavamad.

Kui kasutate GCR-i, soovitan tungivalt kasutada Google Container Builder (GCB) osana oma koostesüsteemist.

Nagu näete, võimaldab selle kasutamine saavutada palju paremaid tulemusi Build+Push operatsiooni kestuse vähendamises kui isegi võimsal masinal – sel juhul kiireneb konteinerite loomise ja saatmise protsess peaaegu kahe korra. Lisaks saate iga päev 120 minutit tasuta ehitamist, mis enamasti rahuldab konteinerite loomise vajadusi.

Edasi liikudes on kõige olulisem jõudlusnäitaja – konteinerite Pull allalaadimiskiirus. Ja kui te ei muretse liiga palju push operatsiooni aja pärast, siis pull protsessi kestus mõjutab tõsiselt süsteemi üldist jõudlust. Oletame, et teil on kolm sõlme sisaldav klaster ja üks neist ebaõnnestub. Kui kasutate haldussüsteemi, nagu Google Kubernetes Engine, asendab see automaatselt rikki läinud sõlme uuega. Kuid see uus sõlm on täiesti tühi, ja te peate kaaluma, kuidas sinna kõik teie konteinerid tõsta, et see hakkaks tööle. Kui pull operatsioon kestab liiga kaua, töötab kogu see aeg teie klaster madalama tootlikkusega.

On olemas palju olukordi, kui selline asi võib juhtuda: see võib olla uue sõlme lisamine klastrisse, sõlmede uuendamine või isegi uuele konteinerile üleminek. Seetõttu muutub pull-aegade minimeerimine võtmeteguriks. On vaieldamatu, et väike konteiner laetakse alla palju kiiremini kui suur. Kui kasutate Kuberneteses mitmeid konteinerid, võib ajasääst olla tõeliselt oluline.

Vaadake allolevat võrdlust: pull-operatsioon väikeste konteinerite korral võtab sõltuvalt masina võimsusest 4–9 korda vähem aega võrreldes sama operatsiooniga, kasutades go:onbuild'i. Väikeste kontseptuaalsete aluskujundite kasutamine kiirendab oluliselt aega ja kiirus, millega uued Kubernetes-sõlmed saavad üles seatud ja internetti ühendatud.

Vaatame turvalisuse küsimust. Arvatakse, et väiksemad konteinerid on palju turvalisemad kui suured, kuna neil on väiksem rünnakupind. Kas see on tõsi? Üks Google Container Registry kasulikest funktsioonidest on võimalus automaatselt skaneerida teie konteinereid haavatavuste suhtes. Mõned kuud tagasi lõin nii onbuild kui ka mitmeastmelised konteinerid, nii et vaatame, kas seal on mingeid haavatavusi.

Tulemus on hämmastav: väiksemas konteineris leiti vaid 3 keskmist haavatavust, samas kui suures on 16 kriitilist ja 376 muud haavatavust. Kui vaadata suures konteineris olevaid komponente, on näha, et enamik turvaprobleeme ei ole seotud meie rakendusega, vaid programmidega, mida me isegi ei kasuta. Seetõttu, kui inimesed räägivad suurest rünnakupinnast, peavad nad silmas just seda.

Kokkuvõte on selge: looge väikseid konteinerid, sest need pakuvad teie süsteemi tõhusust ja turvalisust.

Kubernetesi parimad praktikad. Kubernetesi korraldamine nimespetsiifiliste ruumide abil

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme 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 õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com