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

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

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

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

1. Използвайте естествени механизми за регистриране на контейнери

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

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

2. Уверете се, че контейнерите са без състояние и неизменни

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

без поданство означава, че всяко състояние (постоянни данни от всякакъв вид) се съхранява извън контейнера. За това, в зависимост от нуждите, могат да се използват различни видове външни памети: Cloud съхранение, Постоянни дискове, Redis, Облачен SQL или други управлявани бази данни. (Забележка. превод: Прочетете повече за това в нашата статия „Оператори за Kubernetes: как да стартирате приложения със състояние".)

неизменен означава, че контейнерът няма да бъде модифициран през целия си живот: няма актуализации, корекции, промени в конфигурацията. Ако трябва да актуализирате кода на приложението си или да приложите корекция, създайте ново изображение и го разположете. Препоръчително е да преместите конфигурацията на контейнера (порт за слушане, опции за среда за изпълнение и т.н.) външно - към Тайните и ConfigMaps. Те могат да бъдат актуализирани, без да се налага да създавате ново изображение на контейнер. За лесно създаване на тръбопроводи със сглобяване на изображения можете да използвате Облачно изграждане. (Забележка. превод: Ние използваме инструмент с отворен код за тези цели DAPP.)

Пример за актуализиране на конфигурацията за разполагане в Kubernetes с помощта на ConfigMap, монтиран в pods като конфигурация

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

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

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

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

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

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

5. Направете приложението лесно за наблюдение

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

Табло за управление на Kubernetes на Stackdriver

Prometheus очаква приложението да препраща показатели към крайната точка на HTTP. На разположение за това Клиентски библиотеки на Prometheus. Същият формат се използва от други инструменти като OpenCensus и Истио.

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

Управлението на приложения в производството се подпомага от способността му да съобщава състоянието си на цялата система. Работи ли приложението? Добре ли е? Готови ли сте да получавате трафик? Как се държи? Най-честият начин за решаване на този проблем е прилагането на проверки на здравето (здравни прегледи). Kubernetes има два вида: сонди за жизненост и готовност.

За сонда за оживление (проверки на жизнеността) приложението трябва да има HTTP крайна точка, която връща отговор "200 OK", ако е функционална и нейните основни зависимости са изпълнени. За сонда за готовност (проверки на сервизната готовност) приложението трябва да има друга крайна точка на HTTP, която връща отговор „200 OK“, ако приложението е в добро състояние, стъпките за инициализация са завършени и всяка валидна заявка не води до грешка. Kubernetes ще насочва трафика към контейнера само ако приложението е готово според тези проверки. Две крайни точки могат да бъдат обединени, ако няма разлика между състоянията на жизненост и готовност.

Можете да прочетете повече за това в свързаната статия от Sandeep Dinesh, защитник на разработчиците от Google: „Най-добри практики на Kubernetes: Настройване на проверки на здравето със сонди за готовност и жизненост".

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

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

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

PS от преводача

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

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

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