Я решил отказаться от долгих часов, проведенных за оптимизацией размера Docker-образов.
Несмотря на провокационный заголовок, который мог показаться кликбейтом, я действительно перестал уделять этому столько времени.
Хочу поделиться своими размышлениями - возможно, они окажутся правильными, а может, и нет.
Я не топлю, что мои размышления правильные, я лишь ими делюсь.
Давайте попробую обосновать свою позицию.
Все дальнейшие расчеты будут основаны на работе с облачными провайдерами, хотя, как мне кажется, на bare metal затраты могли бы быть ниже.
Выпущено миллиард книг, написано сотни утилит и опубликовано гигадзиллион статьей по теме оптимизации размера имаджа.
А зачем?
Вспомним основные причины оптимизации размера Docker-образа:
- Ускорение развертывания: Меньшие образы быстрее загружаются и передаются по сети.
- Экономия ресурсов: Снижение потребления дискового пространства и памяти.
- Безопасность: Уменьшение количества компонентов снижает уязвимости.
- Эффективность CI/CD: Ускорение сборки и доставки в конвейерах.
- Снижение затрат: Меньше данных для хранения и передачи в облаке.
и так далее.
Скачивание имаджа.
Когда в основном скачивается имадж:
- при скейле ноды
- при релизе
Есть ещё редкие случаи связок imagePullPolicy Always, скейлинге приложения и антиаффинити, но мы о не будем говорить, они редкие.
А сколько скачивается имадж?
Начиная с версии 1.30 кубера у нас есть метрика
kubelet_image_pull_duration_seconds_sum и лейбл image_size_in_bytes (не сжатый!!!! размер) с 4 значениями ( 0-10MB, 10MB-100MB, 100MB-500MB, 500MB-1GB).Мы говорим про средние имаджи, допустим в 900 мегабайт.
Построим график
avg(kubelet_image_pull_duration_seconds_sum{image_size_in_bytes="500MB-1GB"} / kubelet_image_pull_duration_seconds_count{image_size_in_bytes="500MB-1GB"})
(и для сравнения мелкие имаджи)
avg(kubelet_image_pull_duration_seconds_sum{image_size_in_bytes="100MB-500MB"} / kubelet_image_pull_duration_seconds_count{image_size_in_bytes="100MB-500MB"})
Скорость варьируется от 6 секунд до 16 секунд за последние 7 дней.
Я лично считаю это небольшой цифрой для добавления времени к релизу или скейлингу.
Нода или само приложение порой дольше проходит хелсчеки.
Специально ставил
blackbox exporter + релейбл с путем до проб и навешивал на поды, чтобы рассчитать probe_duration_seconds. Пробы в среднем стартуют с 25 секунд.Экономия ресурсов.
А сколько сейчас стоит в облаках ресурс дискового пространства?
Например у AWS так https://aws.amazon.com/ecr/pricing/
Ну или просто в биллинг можно залезть и посчитать сколько тратим в месяц на ECR.
В среднем за последний год тратим 35-50 долларов в месяц.
Диски для самих нод выходят так мало, что их почти не видно в прайсе
https://aws.amazon.com/ebs/pricing/
Ну то есть в самый пик на дисковое пространство тратим не больше 50 долларов в месяц.
Безопасность.
Я и согласен и несогласен.
Безопасность в последнее время перешла границы от разумного до параноидального бреда, лишь бы мы покупали решения от крупных вендоров и мастурбировали на CVE, которая вышла 0.000001мс назад.
Простые решения в виде "не добавлять ничего лишнего в имадж" + trivy вполне покрывают этот пункт для нас.
Да и уменьшение размера диска не гарантирует безопасность, лишь снижает вероятность инцидентов.
К сожалению в некоторых моих проектах невозможно использовать подходы с SBOM+distroless.
Разработчики пилят микросервисы, макросервисы, сейчас один только nodejs и python тянет за собой миллиард депенденси и отказаться от них невозможно, совершенно невозможно.
А этот софт в отличии от меня приносит деньги.
Эффективность CI/CD
Тот же пункт, что и пул имаджей с нод.
6-16 секунд для несжатых имаджей.
Снижение затрат
Тот же пункт, что и с костами для ECR, но тут за трафик.
Трата за трафик небольшая. Не больше 5 долларов в месяц.