[Перевод] 7 лучших практик по эксплуатации контейнеров по версии Google
Прим. перев.: Автор оригинальной статьи — Théo Chamley, архитектор облачных решений Google. В этой публикации для блога Google Cloud он представил краткую выжимку из более детального руководства его компании, названного «Best Practices for Operating Containers». В нём специалисты Google собрали лучшие практики по эксплуатации контейнеров в контексте использования Google Kubernetes Engine и не только, затронув широкий спектр тем: от безопасности до мониторинга и журналирования. Итак, какие практики в работе с контейнерами наиболее важны по мнению Google?
Kubernetes Engine (основанный на Kubernetes сервис для запуска контейнеризированных приложений в Google Cloud — прим. перев.) — один из лучших способов запуска рабочих нагрузок, нуждающихся в масштабировании. Kubernetes обеспечит беспроблемное функционирование большинства приложений, если они контейнеризированы. Но если вы хотите, чтобы приложением было легко управлять, и хотите воспользоваться всеми преимуществами Kubernetes, необходимо следовать лучшим практикам. Они упростят эксплуатацию приложения, его мониторинг и отладку, а также повысят безопасность.
В этой статье мы пройдёмся по списку того, что стоит знать и делать для эффективного функционирования контейнеров в Kubernetes. Желающим углубиться в детали стоит прочитать материал Best Practices for Operating Containers, а также обратить внимание на наш более ранний пост о сборке контейнеров.
1. Используйте родные механизмы контейнеров для логирования
Если приложение запущено в кластере Kubernetes, для логов нужно не так много. Централизованная система логирования, вероятно, уже встроена в используемый кластер. В случае использования Kubernetes Engine за это отвечает Stackdriver Logging. (Прим. перев.: А в случае использования собственной инсталляции Kubernetes рекомендуем присмотреться к нашему Open Source-решению — 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-контейнеры для выполнения подобных привилегированных операций. Они не нуждаются в доступности ни для внутреннего, ни для внешнего трафика.
Если вы администрируете кластер, можете воспользоваться Pod Security Policy для ограничений в применении привилегированных контейнеров.
4. Избегайте запуска под root
О привилегированных контейнерах уже сказано, но будет ещё лучше, если в дополнение к этому вы не будете запускать под root’ом приложения внутри контейнера. Если злоумышленник найдёт в приложении с правами root удалённую уязвимость с возможностью исполнения кода, после чего сможет выйти из пределов контейнера через пока ещё неизвестную уязвимость, то получит root’а на хосте.
Лучший путь избежать этого — в первую очередь не запускать ничего под root’ом. Для этого можно воспользоваться директивой USER в Dockerfile или runAsUser в Kubernetes. Администратор кластера может также настроить принудительное поведение с помощью Pod Security Policy.
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 best practices: Setting up health checks with readiness and liveness probes».
7. Внимательно выбирайте версию образа
Большинство публичных и приватных образов используют систему тегирования, похожую на описанную в Best Practices for Building Containers. Если образ применяет систему, близкую к семантическому версионированию, необходимо учитывать специфику тегирования. Например, тег latest может часто перемещаться с образа на образ — на него нельзя полагаться, если вам нужны предсказуемые и воспроизводимые сборки и инсталляции.
Можете использовать тег X.Y.Z (они почти всегда неизменны), однако в таком случае отслеживайте все патчи и обновления к образу. Если у используемого образа есть тег X.Y, это хороший вариант золотой середины. Выбрав его, вы автоматически получаете патчи и в то же время опираетесь на стабильную версию приложения.
P.S. от переводчика
Читайте также в нашем блоге:
