Наше приложение состоит из около 20 модулей.Каждый модуль содержит диаграмму (Helm) с несколькими развертываниями, службами и заданиями.Некоторые из этих заданий определены как переустановки Helm и переустановки.Всего, вероятно, около 120 yaml-файлов, что в итоге дает около 50 работающих модулей.
Во время разработки мы запускаем Docker для Windows версии 2.0.0.0-beta-1-win75 с Docker 18.09.0-ce-бета1 и Кубернетес 1.10.3.Чтобы упростить управление нашими yaml-файлами в Kubernetes, мы используем Helm 2.11.0.Docker для Windows настроен на использование 2 ядер ЦП (из 4) и 8 ГБ ОЗУ (из 24 ГБ).
При создании среды приложения в первый раз требуется более 20 минут, чтобы стать доступным,Это кажется слишком медленным;Возможно, мы где-то совершаем важную ошибку.Мы попытались улучшить (пере) время запуска, но безрезультатно.Будем весьма благодарны за любую помощь или советы по улучшению ситуации.
Упрощенная версия нашего сценария запуска:
#!/bin/bash
# Start some infrastructure
helm upgrade --force --install modules/infrastructure/chart
# Start ~20 modules in parallel
helm upgrade --force --install modules/module01/chart &
[...]
helm upgrade --force --install modules/module20/chart &
await_modules()
Повторное выполнение того же сценария запуска позже для «перезагрузки»приложение по-прежнему занимает около 5 минут.Насколько я знаю, неизмененные объекты вообще не модифицируются Кубернетесом.Шлем управляет только примерно 40 крючками.
Запуск одного крючка вручную с помощью docker run быстрый (~ 3 секунды).Регулярный запуск этого же хука через Хелма и Кубернетеса занимает 15 секунд и более.
Ниже перечислены некоторые вещи, которые мы обнаружили и попробовали.
Промежуточная среда Linux
Наша промежуточная средасостоит из Ubuntu с родным Docker.Kubernetes устанавливается через minikube с --vm-driver none.
В отличие от нашей локальной среды разработки, промежуточная среда извлекает код приложения через (устаревший) том gitRepo почти для каждого развертывания и задания.Понятно, что это только усугубляет проблему.Первый запуск среды занимает более 25 минут, а перезапуск занимает около 20 минут.
Мы попытались заменить том gitRepo контейнером с коляской, который получает код приложения в виде TAR.Хотя мы не модифицировали приложение целиком, начальные тесты показывают, что это не особенно быстро, чем том gitRepo.
Эту ситуацию, вероятно, можно улучшить с помощью альтернативного типа тома, который позволяет совместно использовать код между развертываниями ирабочие места.Мы бы предпочли не вводить больше сложности, поэтому мы больше не будем исследовать этот путь.
Время запуска Docker
Выполнение одного пустого альпийского контейнера через docker run alpine echo "test" занимает примерно 2 секунды.Кажется, это накладные расходы на установку в Windows.Эта же команда занимает меньше 0,5 секунды в нашей промежуточной среде Linux.
Совместное использование тома Docker
Большинство контейнеров, включая хуки, обмениваются кодом с хостом через hostPath.Команда docker run -v <host path>:<container path> alpine echo "test" занимает 3 секунды.Использование томов увеличивает время выполнения примерно на 1 секунду.
Параллельное или последовательное
Последовательное выполнение команд в сценарии запуска не увеличивает время запуска.И при этом это не ухудшается значительно.
IO-связанный?
Диспетчер задач Windows указывает, что IO находится на 100% при выполнении сценария запуска.Наши хуки и код приложения вообще не требуют интенсивного ввода-вывода.Таким образом, нагрузка ввода-вывода, кажется, происходит из Docker, Kubernetes или Helm.Мы пытались найти узкое место, но не смогли точно определить причину.
Снижение ввода-вывода с помощью виртуального диска
Чтобы проверить предпосылку дальнейшего связывания ввода-вывода, мы обменялись /var/lib/docker с виртуальным дискомв нашей среде подготовки Linux.Запуск приложения с этой конфигурацией не был значительно быстрее.