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

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

Kubernetes Engine (услугата за стартиране на контейнеризирани приложения в Google Cloud, базирана на Kubernetes — прим. прев.) — един от най-добрите начини за стартиране на работни натоварвания, които изискват мащабиране. 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 права. Същите разсъждения важат и за избягването на привилегировани контейнери. Ако е необходимо да променяте настройки на хоста, можете да предоставите на контейнера конкретни възможности чрез опцията 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, това е добър вариант на златната среда. Избирайки го, автоматично получавате пачове и в същото време разчитате на стабилна версия на приложението.