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

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

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

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

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

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

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

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

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

С това обновление получавате контейнер с десет пъти по-малък размер. Ако вашият език за програмиране или стек не предлага функция за намаляване на основния образ, използвайте 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 E5-2650 v4 на стойност 9000 евро за малко пари?

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