7 най-добри практики за експлоатация на контейнери според Google

Прим. прев.: Автор на оригиналната статия е Théo Chamley, архитект на облачни решения в Google. В тази публикация за блога на Google Cloud той представя кратък преглед на по-подробно ръководство на неговата компания, наречено «Най-добри практики за работа с контейнери». В него специалисти от Google са събрали най-добрите практики за експлоатация на контейнери в контекста на използването на Google Kubernetes Engine и не само, засегнали широк спектър от теми: от безопасност до мониторинг и журналиране. И така, кои практики при работа с контейнери са най-важни според Google?

Kubernetes Engine (основаващ се на Kubernetes сервис за стартиране на контейнеризирани приложения в Google Cloud — бел. прев.) — това е един от най-добрите начини за стартиране на натоварвания, които изискват мащабиране. Kubernetes осигурява безпроблемно функциониране на повечето приложения, ако те са контейнеризирани. Но ако искате приложението да бъде лесно за управление и да се възползвате от всичките предимства на Kubernetes, е необходимо да следвате най-добрите практики. Те ще улеснят експлоатацията на приложението, неговия мониторинг и отстраняване на проблеми, а също така ще повишат безопасността.

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

1. Използвайте родни механизми на контейнерите за журналиране

Ако приложението работи в кластер Kubernetes, не са необходими много неща за логовете. Централизирана система за журнализиране вероятно вече е вградена в използвания кластер. В случай на използване на Kubernetes Engine, за това отговаря Stackdriver Logging. (Прим. прев.: А при използване на собствена инсталация на Kubernetes, ви препоръчваме да се запознаете с нашето решение с отворен код — loghouse.) Не усложнявайте живота си и използвайте родните механизми на контейнерите за журналиране. Пишете логовете в stdout и stderr — те ще бъдат автоматично получени, запазени и индексирани.

При желание можете също така да пишете логове в формат JSON.. Този подход ще позволи лесно добавяне на метаданни. А заедно с тях в Stackdriver Logging ще се появи възможността за търсене в логовете с използване на тези метаданни.

2. Убедете се, че контейнерите са stateless и immutable

За правилното функциониране на контейнерите в Kubernetes клъстер, те трябва да бъдат stateless и immutable. Когато тези условия са изпълнени, Kubernetes ще може да изпълнява своята работа, създавайки и унищожавайки приложения, когато и където е необходимо.

Stateless означава, че всяко състояние (постоянни данни от всякакъв вид) се съхранява извън контейнера. За това, в зависимост от нуждите, могат да се използват различни видове външни хранилища: Cloud Storage, Persistent Disks, Redis, Cloud SQL или други управлявани бази данни. (Прим. прев.: За повече информация прочетете също в нашата статия „Оператори за Kubernetes: как да стартирате stateful приложения».)

Immutable означава, че контейнерът няма да бъде модифициран през своя живот: никакви ъпдейти, пачове, промени в конфигурацията. Ако нужно е да обновите код на приложението или да приложите пач, създайте нов образ и го деплойте. Препоръчваме да изнасяте конфигурацията на контейнера (порт за слушане, опции на изплнителната среда и т.н.) навън — в Secrets и ConfigMaps. Те могат да бъдат обновявани без необходимост от компилиране на нов контейнерен образ. За лесно създаване на пайплайни за компилиране на образи можете да използвате Cloud Build. (Прим. прев.: Ние за тези нужди използваме Open Source инструмент dapp.)

Пример за обновяване на конфигурацията на Deployment в Kubernetes с помощта на ConfigMap, монтиран в подовете като конфигурация.

3. Избягвайте привилегировани контейнери.

Не наливаш приложения под root на своите сървъри, нали? Ако злонамереното лице проникне в приложението, то получава достъп с права root. Същите разсъждения важат и за недопускане на привилегировани контейнери. Ако е нужно да промените настройки на хоста, можете да предоставите на контейнера конкретни capabilities чрез опция securityContext в Kubernetes. Ако е необходимо да промените sysctls, Kubernetes има отделна анотация за това. А всъщност, опитайте се максимално да използвате init- и sidecar контейнери за извършване на подобни привилегировани операции. Те не изискват достъпност нито за вътрешен, нито за външен трафик.

Ако администрирате клъстера, можете да се възползвате от Политика за сигурност на пода за ограничения при прилагането на привилегировани контейнери.

4. Избягвайте стартиране под root.

Изказвалось е за привилегированите контейнери, но ще бъде още по-добре, ако в допълнение към това не стартирате приложения под root в контейнера. Ако атакуващият открие отдалечена уязвимост с възможност за изпълнение на код в приложение с права root, след което може да излезе извън границите на контейнера чрез все още неизвестна уязвимост, ще получи root на хоста.

Най-добрият начин да избегнете това е първо да не стартирате нищо под root. За целта можете да използвате директивата USER в Dockerfile или runAsUser в Kubernetes. Администраторът на кластера може също да настрои принудително поведение с помощта на Политика за сигурност на пода.

5. Направете приложението лесно за мониторинг

Както логването, мониторингът е неотменима част от управлението на приложението. Популярно решение за мониторинг в общността на Kubernetes е Prometheus — система, която автоматично открива подове и услуги, изискващи мониторинг. (Прим. прев.: Вижте също нашия подробен доклад по темата за мониторинг с Prometheus и Kubernetes.) Stackdriver е способен да мониторира Kubernetes клъстери и включва своя версия на Prometheus за мониторинг на приложения.

Контролният панел на Kubernetes в Stackdriver

Prometheus очаква приложението да предостави метрики на HTTP endpoint. За целта са налични клиентски библиотеки Prometheus. Същият формат използват и други инструменти като OpenCensus и Istio.

6. Направете състоянието на приложението достъпно

Управлението на приложението в production помага за способността му да информира системата за своето състояние. Започнато ли е приложението? В ред ли е? Готово ли е да приема трафик? Как се държи? Най-разпространеният начин за решаване на този проблем е реализирането на проверки за здравословно състояние (health checks). В Kubernetes има два техни типа: liveness и readiness probes.

За liveness probe (проверка на жизнеспособност) приложението трябва да има HTTP endpoint, който да връща отговор «200 OK», ако функционира и основните му зависимости са удовлетворени. За readiness probe (проверка на готовност за обслужване) Приложението трябва да има друг HTTP endpoint, който връща отговор «200 OK», ако приложението е в здраво състояние, стъпките за инициализация са изпълнени и всяко валидно запитване не води до грешка. Kubernetes ще насочва трафика към контейнера само при готовност на приложението в съответствие с тези проверки. Двата endpoint-а могат да бъдат обединени, ако разликата между състоянията на жизнеспособност (liveness) и готовност (readiness) няма.

По-подробно за това можете да прочетете в съответната статия на Sandeep Dinesh, Developer Advocate от Google: «Най-добри практики за Kubernetes: Настройка на проверки за здравето с проверки за готовност и жизнеспособност».

7. Внимателно изберете версията на образа

Повечето публични и частни образи използват система за етикетиране, подобна на описаната в Най-добри практики за изграждане на контейнери. Ако образът прилага система, близка до семантичното версиониране, е необходимо да се вземе предвид спецификата на етикетирането. Например, етикетът latest може често да се прехвърля от образ на образ — не може да се разчита на него, ако имате нужда от предсказуеми и възпроизвеждаеми сборки и инсталации.

Можете да използвате етикета X.Y.Z (те почти винаги остават непроменени), обаче в този случай проследявайте всички пачове и актуализации на образа. Ако използваният образ има етикет X.Y, това е добър вариант на средно решение. Избирайки го, автоматично получавате пачове и в същото време разчитате на стабилна версия на приложението.

P.S. от преводача

Прочетете също в нашия блог:

• «Нова статистика от CNCF за контейнери, cloud native и Kubernetes»;
• «7 принципа на проектиране на приложения, базирани на контейнери»;
• «11 начина (не) да станете жертва на хакерска атака в Kubernetes»;
• «Нашият опит с Kubernetes в малки проекти» (обзор и видео на доклада);
• «Мониторинг и Kubernetes» (обзор и видео на доклада);
• «Събиране на Docker-образи за CI/CD бързо и удобно заедно с dapp» (обзор и видео на доклада);
• «Практики за Continuous Delivery с Docker» (обзор и видео на доклада);
• «Смъртта на микросервисното безумие през 2018 година».

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