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

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

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

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

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

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

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

За да преминете към по-малък базов образ, просто обновете Docker файла, за да започнете работа с новия базов образ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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