Guest
Контейнеры — полезные инструменты разработки, но их часто воспринимают как должное, не задумываясь о повышении их эффективности. Например, есть средства, автоматически собирающие контейнеры за нас, такие как Paketo Buildpack для Spring Boot приложений. Но при автоматической сборке мы получаем либо «черный ящик» с начинкой, не подходящей для наших нужд, либо случайные образы, которые могут содержать устаревшую версию Java или неэффективные скрипты. Использование автоматически собранных контейнеров становится проблемой при увеличении нагрузки и количества инстансов. По сути, заоблачных счетов за облачные ресурсы можно было бы избежать, использовав оптимальные контейнеры. А для этого нужно вовлечь разработчиков в процесс оптимизации деплоймента. Оптимизация подразумевает под собой следующее: — уменьшение время создания контейнера, а следовательно, и срока вывода продукта на рынок; — упрощение процесса создания контейнеров и разработки в целом, включая тестирование и вывод в производство; — соблюдение баланса между созданием и обкаткой контейнеров и оптимизацией использования ресурсов. Помня о предыдущем докладе «Не клади все яйца в один контейнер», можно догадаться, что если мы положим случайные яйца в наш контейнер, Kubernetes не улучшит ситуацию, а просто масштабирует неоптимальные сущности. Используя K8s, важно понимать: — как могут проявиться проблемы, связанные с неэффективными контейнерами, при масштабировании; — как с с этими проблемами бороться; — что делают конфигурируемые скрипты и как повысить их эффективность; — сколько мы потеряем в производительности, если не будем предпринимать никаких действий. Что можно сделать в сложившейся ситуации? Можно оптимизировать контейнеры с помощью встроенных инструментов, а можно собирать контейнеры самостоятельно и уже потом интегрировать в рабочий процесс K8s. В своем докладе Дмитрий покажет, на что следует обратить внимание при последнем подходе. Кроме того, речь пойдет про технологию Native Image, так как все обозначенные выше проблемы и задачи применимы и к ней.
