Най-добри практики на Kubernetes. Създаване на малки контейнери

Първата стъпка от внедряването в Kubernetes е поставянето на вашето приложение в контейнер. В тази поредица ще разгледаме как можете да създадете малко, защитено изображение на контейнер.
Благодарение на Docker създаването на изображения на контейнери никога не е било по-лесно. Посочете основно изображение, добавете вашите промени и създайте контейнер.

Въпреки че тази техника е чудесна за започване, използването на базови изображения по подразбиране може да доведе до опасна работа с големи изображения, пълни с уязвимости.

Освен това повечето изображения в Docker използват Debian или Ubuntu за базово изображение и докато това осигурява отлична съвместимост и лесна персонализация (докер файл отнема само два реда код), базовите изображения могат да добавят стотици мегабайти допълнително натоварване към вашия контейнер. Например, един прост файл node.js за приложение Go „hello-world“ е около 700 мегабайта, докато действителното ви приложение е с размер само няколко мегабайта.

Така че цялата тази допълнителна работа е загуба на цифрово пространство и чудесно скривалище за уязвимости и грешки в сигурността. Така че нека да разгледаме два начина за намаляване на размера на изображение на контейнер.

Първият е използването на малки базови изображения, вторият е използването на модела Builder. Използването на по-малки основни изображения вероятно е най-лесният начин да намалите размера на вашия контейнер. Най-вероятно езикът или стекът, който използвате, предоставя оригинално изображение на приложение, което е много по-малко от изображението по подразбиране. Нека да разгледаме нашия контейнер node.js.

По подразбиране в Docker размерът на базовото изображение node:8 е 670 MB, а размерът на изображението node: 8-alpine е само 65 MB, тоест 10 пъти по-малък. Като използвате по-малкото базово изображение на Alpine, вие значително ще намалите размера на вашия контейнер. Alpine е малка и лека дистрибуция на Linux, която е много популярна сред потребителите на Docker, защото е съвместима с много приложения, като същевременно поддържа малки контейнери. За разлика от стандартното изображение на Docker "node", "node:alpine" премахва много сервизни файлове и програми, оставяйки само тези, които са достатъчни за стартиране на вашето приложение.

За да преминете към по-малко основно изображение, просто актуализирайте Dockerfile, за да започнете да работите с новото основно изображение:

Сега, за разлика от старото изображение на onbuild, трябва да копирате кода си в контейнера и да инсталирате всички зависимости. В нов Dockerfile контейнерът започва с изображение node:alpine, след това създава директория за кода, инсталира зависимости с помощта на мениджъра на пакети NPM и накрая изпълнява server.js.

Това надграждане води до контейнер, който е 10 пъти по-малък по размер. Ако вашият програмен език или стек няма функционалност за намаляване на базовото изображение, използвайте Alpine Linux. Той също така ще осигури възможност за пълно управление на съдържанието на контейнера. Използването на малки основни изображения е чудесен начин за бързо създаване на малки контейнери. Но още по-голямо намаление може да се постигне с помощта на Builder Pattern.

В интерпретираните езици изходният код първо се предава на интерпретатора и след това директно се изпълнява. В компилираните езици изходният код първо се преобразува в компилиран код. Компилирането обаче често използва инструменти, които всъщност не са необходими за изпълнение на кода. Това означава, че можете напълно да премахнете тези инструменти от крайния контейнер. Можете да използвате Builder Pattern за това.

Кодът се създава в първия контейнер и се компилира. След това компилираният код се пакетира в окончателен контейнер без компилатори и инструменти, необходими за компилиране на този код. Нека стартираме Go приложение през този процес. Първо, ще преминем от onbuild изображението към Alpine Linux.

В новия Dockerfile контейнерът започва с golang:alpine изображение. След това създава директория за кода, копира го в изходния код, изгражда този изходен код и изпълнява приложението. Този контейнер е много по-малък от контейнера onbuild, но все пак съдържа компилатора и други Go инструменти, които всъщност не са ни необходими. Така че нека просто извлечем компилираната програма и я поставим в нейния собствен контейнер.

Може да забележите нещо странно в този Docker файл: той съдържа два реда FROM. Първият раздел от 4 реда изглежда абсолютно същият като предишния Dockerfile, с изключение на това, че използва ключовата дума AS за име на този етап. Следващият раздел има нов ред FROM за започване на ново изображение, където вместо изображението golang:alpine ще използваме Raw alpine като основно изображение.

Raw Alpine Linux няма инсталирани SSL сертификати, което ще доведе до неуспех на повечето API извиквания през HTTPS, така че нека инсталираме някои главни CA сертификати.

Сега идва забавната част: за да копирате компилирания код от първия контейнер във втория, можете просто да използвате командата COPY, разположена на ред 5 от втория раздел. Той ще копира само един файл на приложението и няма да засегне инструментите на помощната програма Go. Новият многоетапен Docker файл ще съдържа изображение на контейнер с размер само 12 мегабайта, в сравнение с оригиналното изображение на контейнер, което беше 700 мегабайта, което е голяма разлика!
Така че използването на малки основни изображения и Builder Pattern са страхотни начини за създаване на много по-малки контейнери без много работа.
Възможно е в зависимост от стека на приложението да има допълнителни начини за намаляване на размера на изображението и контейнера, но наистина ли малките контейнери имат измерима полза? Нека разгледаме две области, в които малките контейнери са изключително ефективни – производителност и сигурност.

За да оцените увеличението на производителността, помислете за продължителността на процеса на създаване на контейнер, вмъкването му в регистъра (натискане) и след това извличането му от там (изтегляне). Можете да видите, че по-малкият контейнер има определено предимство пред по-големия контейнер.

Docker ще кешира слоевете, така че следващите компилации ще бъдат много бързи. Въпреки това, много CI системи, използвани за изграждане и тестване на контейнери, не кешират слоеве, така че има значителни спестявания на време. Както можете да видите, времето за изграждане на голям контейнер, в зависимост от мощността на вашата машина, е от 34 до 54 секунди, а при използване на контейнер, намалено с помощта на Builder Pattern - от 23 до 28 секунди. При операции от този вид увеличението на производителността ще бъде 40-50%. Така че просто помислете колко пъти създавате и тествате своя код.

След като контейнерът е изграден, трябва да изпратите изображението му (изображение на push контейнер) в регистъра на контейнера, така че след това да можете да го използвате във вашия клъстер Kubernetes. Препоръчвам да използвате Google Container Registry.

С Google Container Registry (GCR) плащате само за необработено съхранение и работа в мрежа и няма допълнителни такси за управление на контейнери. Той е частен, сигурен и много бърз. GCR използва много трикове, за да ускори операцията по изтегляне. Както можете да видите, вмъкването на контейнер Docker Container Image с помощта на go:onbuild ще отнеме от 15 до 48 секунди, в зависимост от производителността на компютъра, а същата операция с по-малък контейнер ще отнеме от 14 до 16 секунди и за по-малко продуктивни машини предимството в скоростта на работа се увеличава 3 пъти. За по-големи машини времето е приблизително същото, тъй като GCR използва глобален кеш за споделена база данни от изображения, което означава, че изобщо не е необходимо да ги зареждате. В компютър с ниска мощност процесорът е тясното място, така че предимството от използването на малки контейнери тук е много по-голямо.

Ако използвате GCR, силно препоръчвам да използвате Google Container Builder (GCB) като част от вашата система за изграждане.

Както можете да видите, използването му ви позволява да постигнете много по-добри резултати при намаляване на продължителността на операцията Build+Push, отколкото дори продуктивна машина - в този случай процесът на изграждане и изпращане на контейнери към хоста се ускорява почти 2 пъти . Освен това получавате 120 безплатни минути за изграждане всеки ден, което покрива нуждите ви за изграждане на контейнери в повечето случаи.

Следва най-важният показател за ефективност – скоростта на извличане или изтегляне на Pull контейнери. И ако не ви пука много за времето, прекарано в операция за изтегляне, тогава продължителността на процеса на изтегляне оказва сериозно влияние върху цялостната производителност на системата. Да приемем, че имате клъстер от три възела и един от тях се проваля. Ако използвате система за управление като Google Kubernetes Engine, тя автоматично ще замени мъртвия възел с нов. Този нов възел обаче ще бъде напълно празен и ще трябва да плъзнете всичките си контейнери в него, за да започне да работи. Ако операцията по изтегляне отнеме достатъчно време, вашият клъстер ще работи с по-ниска производителност през цялото време.

Има много случаи, в които това може да се случи: добавяне на нов възел към клъстер, надграждане на възли или дори преминаване към нов контейнер за внедряване. По този начин минимизирането на времето за екстракция на изтегляне се превръща в ключов фактор. Не може да се отрече, че малък контейнер се изтегля много по-бързо от голям. Ако използвате множество контейнери в клъстер на Kubernetes, спестяванията на време могат да бъдат значителни.

Обърнете внимание на това сравнение: операция за изтегляне на малки контейнери отнема 4-9 пъти по-малко време, в зависимост от мощността на машината, отколкото същата операция, използваща go:onbuild. Използването на споделени малки базови изображения на контейнери значително ускорява времето и скоростта, с която новите възли на Kubernetes могат да бъдат разгърнати и да станат онлайн.

Нека разгледаме въпроса за сигурността. По-малките контейнери се считат за много по-безопасни от по-големите, тъй като имат по-малка повърхност за нападение. Наистина ли е? Една от най-полезните функции на Google Container Registry е възможността за автоматично сканиране на вашите контейнери за уязвимости. Преди няколко месеца създадох както onbuild, така и многоетапни контейнери, така че нека да видим дали има някакви уязвимости там.

Резултатът е невероятен: само 3 средни уязвимости бяха открити в малък контейнер, а 16 критични и 376 други уязвимости бяха открити в голям контейнер. Ако погледнем съдържанието на голям контейнер, можем да видим, че повечето проблеми със сигурността нямат нищо общо с нашето приложение, а са свързани с програми, които дори не използваме. Така че, когато хората говорят за голяма повърхност за атака, това имат предвид.

Изводът е ясен: изградете малки контейнери, защото те осигуряват реални ползи за производителност и сигурност на вашата система.

Най-добри практики на Kubernetes. Kubernetes организация с пространство от имена

Малко реклами 🙂

Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, облачен VPS за разработчици от $4.99, уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да споделите сървър? (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV от $199 в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за Как да изградим инфраструктура Corp. клас с използване на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за стотинка?

Източник: www.habr.com