Создание оптимизированных контейнеров для Kubernetes

Docker создает новый слой изображения каждый раз, когда выполняет инструкциюRUN,COPY илиADD. Если вы соберете образ снова, механизм сборки проверит каждую инструкцию, чтобы увидеть, есть ли на нем слой изображения, кэшированный для этой операции. Если он находит совпадение в кэше, он использует существующий слой изображения, а не выполняет инструкцию снова и перестраивает слой.

Этот процесс может значительно сократить время сборки, но важно понимать механизм, используемый для избежания потенциальных проблем. Для инструкций по копированию файлов, таких какCOPY иADD, Docker сравнивает контрольные суммы файлов, чтобы увидеть, нужно ли выполнить операцию снова. Для инструкцийRUN Docker проверяет, есть ли у него существующий слой изображения, кэшированный для этой конкретной командной строки.

Хотя это может быть неочевидно сразу, это поведение может привести к неожиданным результатам, если вы не будете осторожны. Типичным примером этого является обновление локального индекса пакета и установка пакетов в два отдельных этапа. В этом примере мы будем использовать Ubuntu, но основная предпосылка в равной степени применима к базовым образам для других дистрибутивов:

Пример установки пакета Dockerfile

Здесь индекс локального пакета обновляется в одной инструкцииRUN (apt -y update), а Nginx устанавливается в другой операции. Это работает без проблем при первом использовании. Однако, если Dockerfile обновляется позже для установки дополнительного пакета, могут возникнуть проблемы:

Пример установки пакета Dockerfile

Мы добавили второй пакет в команду установки, запускаемую второй инструкцией. Если со времени предыдущей сборки образа прошло значительное количество времени, новая сборка может завершиться ошибкой. Это связано с тем, что в инструкции обновления индекса пакета (RUN apt -y update) измененnot, поэтому Docker повторно использует слой изображения, связанный с этой инструкцией. Поскольку мы используем старый индекс пакета, версия пакетаphp-fpm, которая есть в наших локальных записях, может больше не находиться в репозиториях, что приводит к ошибке при выполнении второй инструкции.

Чтобы избежать этого сценария, обязательно объедините все взаимозависимые шаги в одну инструкциюRUN, чтобы Docker повторно выполнил все необходимые команды, когда произойдет изменение:

Пример установки пакета Dockerfile

Теперь инструкция обновляет локальный кеш пакетов при каждом изменении списка пакетов.

Предыдущий пример демонстрирует, как поведение кэширования Docker может ниспровергнуть ожидания, но есть еще кое-что, о чем следует помнить о том, как инструкцииRUN взаимодействуют с системой слоев Docker. Как упоминалось ранее, в конце каждой инструкцииRUN Docker фиксирует изменения как дополнительный слой изображения. Чтобы контролировать область создаваемых слоев изображений, вы можете очистить ненужные файлы в конечной среде, которые будут зафиксированы, обращая внимание на артефакты, представленные выполняемыми вами командами.

В общем, объединение команд в единую инструкциюRUN обеспечивает большой контроль над слоем, который будет записан. Для каждой команды вы можете настроить состояние слоя (apt -y update), выполнить основную команду (apt install -y nginx php-fpm) и удалить все ненужные артефакты, чтобы очистить среду до ее фиксации. Например, многие Dockerfiles связываютrm -rf /var/lib/apt/lists/* в конец командapt, удаляя индексы загруженных пакетов, чтобы уменьшить окончательный размер слоя:

Пример установки пакета Dockerfile

Для дальнейшего уменьшения размера слоев изображений, которые вы создаете, может быть полезна попытка ограничить другие непреднамеренные побочные эффекты команд, которые вы запускаете. Например, в дополнение к явно объявленным пакетам,apt также по умолчанию устанавливает «рекомендуемые» пакеты. Вы можете включить--no-install-recommends в свои командыapt, чтобы устранить это поведение. Возможно, вам придется поэкспериментировать, чтобы выяснить, используете ли вы какие-либо функции, предоставляемые рекомендованными пакетами.

Мы использовали команды управления пакетами в этом разделе в качестве примера, но эти же принципы применимы и к другим сценариям. Общая идея состоит в том, чтобы создать предварительные условия, выполнить минимальную жизнеспособную команду, а затем очистить все ненужные артефакты с помощью одной командыRUN, чтобы уменьшить накладные расходы на слой, который вы будете создавать.

Multi-stage builds были введены в Docker 17.05, что позволяет разработчикам более жестко контролировать конечные образы среды выполнения, которые они создают. Многоступенчатые сборки позволяют разделить файл Dockerfile на несколько разделов, представляющих отдельные этапы, каждый с операторомFROM для указания отдельных родительских образов.

Предыдущие разделы определяют изображения, которые можно использовать для создания приложения и подготовки ресурсов. Они часто содержат инструменты сборки и файлы разработки, которые необходимы для создания приложения, но не являются необходимыми для его запуска. Каждый последующий этап, определенный в файле, будет иметь доступ к артефактам, созданным на предыдущих этапах.

Последний операторFROM определяет изображение, которое будет использоваться для запуска приложения. Как правило, это урезанный образ, который устанавливает только необходимые требования времени выполнения, а затем копирует артефакты приложения, созданные на предыдущих этапах.

Эта система позволяет вам меньше беспокоиться об оптимизации инструкцийRUN на этапах сборки, поскольку эти уровни контейнера не будут присутствовать в окончательном образе среды выполнения. Вы все равно должны обращать внимание на то, как инструкции взаимодействуют с кэшированием слоев на этапах сборки, но ваши усилия могут быть направлены на минимизацию времени сборки, а не окончательного размера изображения. Уделение внимания инструкциям на заключительном этапе все еще важно для уменьшения размера изображения, но, разделяя различные этапы построения контейнера, проще получить упорядоченные изображения без такой большой сложности Dockerfile.

Как правило, рекомендуется упаковывать каждый фрагмент независимых функций в отдельный образ контейнера.

Это отличается от распространенных стратегий, используемых в средах виртуальных машин, где приложения часто группируются в одном образе, чтобы уменьшить размер и минимизировать ресурсы, необходимые для работы виртуальной машины. Поскольку контейнеры - это легкие абстракции, которые не виртуализируют весь стек операционной системы, этот компромисс менее убедителен для Kubernetes. Таким образом, хотя виртуальная машина веб-стека может объединять веб-сервер Nginx с сервером приложений Gunicorn на одной машине для обслуживания приложения Django, в Кубернетесе они могут быть разделены на отдельные контейнеры.

Разработка контейнеров, в которых реализована одна отдельная функциональность для ваших услуг, предлагает ряд преимуществ. Каждый контейнер может быть разработан независимо, если установлены стандартные интерфейсы между сервисами. Например, контейнер Nginx может потенциально использоваться для прокси для нескольких разных бэкэндов или может использоваться в качестве балансировщика нагрузки, если задана другая конфигурация.

После развертывания каждый образ контейнера можно масштабировать независимо, чтобы учесть различные ресурсы и ограничения нагрузки. Разделив ваши приложения на несколько образов контейнеров, вы получаете гибкость в разработке, организации и развертывании.

В Kubernetespods - это наименьшая единица, которой может напрямую управлять плоскость управления. Модули состоят из одного или нескольких контейнеров вместе с дополнительными данными конфигурации, чтобы сообщить платформе, как должны выполняться эти компоненты. Контейнеры в модуле всегда планируются на одном рабочем узле в кластере, и система автоматически перезапускает отказавшие контейнеры. Абстракция pod очень полезна, но она вводит еще один уровень решений о том, как объединять компоненты ваших приложений.

Как и изображения контейнеров, модули также становятся менее гибкими, когда слишком много функций объединено в одну сущность. Сами модули могут быть масштабированы с использованием других абстракций, но контейнеры внутри них не могут управляться или масштабироваться независимо. Поэтому, чтобы продолжить использование нашего предыдущего примера, отдельные контейнеры Nginx и Gunicorn, вероятно, не следует объединять в один модуль, чтобы их можно было контролировать и развертывать отдельно.

Однако существуют сценарии, в которых имеет смысл объединить функционально разные контейнеры в единое целое. В общем случае их можно отнести к разряду ситуаций, когда дополнительный контейнер поддерживает или расширяет основные функции основного контейнера или помогает ему адаптироваться к среде развертывания. Некоторые общие шаблоны:

Как вы могли заметить, каждый из этих шаблонов поддерживает стратегию создания стандартных общих образов первичных контейнеров, которые затем могут быть развернуты в различных контекстах и ​​конфигурациях. Вторичные контейнеры помогают устранить разрыв между основным контейнером и конкретной используемой средой развертывания. Некоторые контейнеры с коляской также могут быть повторно использованы для адаптации нескольких основных контейнеров к одинаковым условиям окружающей среды. Эти шаблоны извлекают выгоду из общей файловой системы и сетевого пространства имен, предоставляемых абстракцией pod, при этом обеспечивая независимую разработку и гибкое развертывание стандартизированных контейнеров.

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

Хосты управляют событиями жизненного цикла контейнера, отправляя сигналы процессу, работающему как PID (ID процесса) 1 внутри контейнера. PID 1 - это первый запущенный процесс, который будет системой init в традиционных вычислительных средах. Однако, поскольку хост может управлять только PID 1, использование обычной системы инициализации для управления процессами в контейнере иногда означает, что нет способа контролировать основное приложение. Хост может запускать, останавливать или уничтожать внутреннюю систему инициализации, но не может напрямую управлять основным приложением. Сигналы иногда распространяют предполагаемое поведение на работающее приложение, но это добавляет сложности и не всегда необходимо.

В большинстве случаев лучше упростить рабочую среду внутри контейнера, чтобы PID 1 выполнял основное приложение на переднем плане. В случаях, когда необходимо запустить несколько процессов, PID 1 отвечает за управление жизненным циклом последующих процессов. Некоторые приложения, такие как Apache, обрабатывают это изначально, порождая и управляя работниками, которые обрабатывают соединения. Для других приложений в некоторых случаях может использоваться сценарий оболочки или очень простая система инициализации, напримерdumb-init, или включенная система инициализацииtini. Независимо от выбранной вами реализации, процесс, работающий как PID 1 в контейнере, должен соответствующим образом реагировать на сигналыTERM, отправленные Kubernetes, чтобы вести себя должным образом.

Внедрения и сервисы Kubernetes предлагают управление жизненным циклом для длительных процессов и надежный постоянный доступ к приложениям, даже когда необходимо перезапустить базовые контейнеры или изменить сами реализации. Сняв с себя ответственность за мониторинг и поддержание работоспособности сервиса из контейнера, вы можете использовать инструменты платформы для управления работоспособными рабочими нагрузками.

Чтобы Kubernetes правильно управлял контейнерами, он должен понимать, являются ли работающие в контейнерах приложения работоспособными и способными выполнять работу. Чтобы включить это, контейнеры могут реализовывать датчики жизнеспособности: конечные точки сети или команды, которые можно использовать для сообщения о работоспособности приложения. Kubernetes будет периодически проверять определенные датчики жизнеспособности, чтобы определить, работает ли контейнер, как ожидалось. Если контейнер не отвечает соответствующим образом, Kubernetes перезапускает контейнер в попытке восстановить функциональность.

Kubernetes также предоставляет зонды готовности, похожую конструкцию. Вместо того, чтобы указывать на работоспособность приложения в контейнере, зонды готовности определяют, готово ли приложение к приему трафика. Это может быть полезно, когда контейнерное приложение имеет подпрограмму инициализации, которая должна завершиться, прежде чем оно будет готово для получения соединений. Kubernetes использует датчики готовности, чтобы определить, следует ли добавить модуль в службу или удалить модуль из службы.

Определение конечных точек для этих двух типов зондов может помочь Kubernetes эффективно управлять вашими контейнерами и предотвратить влияние проблем жизненного цикла контейнеров на доступность услуг. Механизмы реагирования на такие запросы работоспособности должны быть встроены в само приложение и должны быть представлены в конфигурации образа Docker.