Як оптимізувати Kubernetes для великих зображень Docker

Короткий огляд проблеми Одного разу під час запланованого оновлення кластера k8s ми виявили, що майже всі наші POD (приблизно 500 з 1000) на нових вузлах не можуть запуститися, і хвилини швидко перетворилися на години. Ми активно шукаємо першопричину, але через три години PODS все ще перебував у статусі . ContainerCreating На щастя, це не було робоче середовище, тому період обслуговування було заплановано на вихідні. Ми мали час дослідити проблему без жодного тиску. З чого почати пошук першопричини? Хочете дізнатися більше про рішення, яке ми знайшли? Пристебніться та насолоджуйтесь! Детальніше про проблему Проблема полягала в тому, що ми мали велику кількість образів докерів, які потрібно було отримати та запустити на кожному вузлі в кластері одночасно. Це сталося через те, що кілька одночасних завантажень образів докерів на одному вузлі можуть призвести до високого використання диска та збільшення часу холодного запуску. Час від часу процес обробки компакт-диска займає до 3 годин, щоб отримати зображення. Однак цього разу він повністю застряг, оскільки кількість PODS під час оновлення EKS (inline, коли ми замінюємо всі вузли в кластері) була занадто великою. Усі наші програми працюють у k8s (на базі ). Щоб заощадити на наших витратах на DEV env, ми використовуємо точкові екземпляри. EKS Ми використовуємо образ для вузлів. AmazonLinux2 У нас є велика кількість (FB) у середовищі розробки, які постійно розгортаються в нашому кластері Kubernetes. Кожен FB має власний набір програм, і кожна програма має власний набір залежностей (всередині зображення). гілок функцій У нашому проекті майже 200 додатків і ця кількість зростає. Кожна програма використовує одне із 7 базових зображень докерів розміром ~2 ГБ. Максимальний загальний розмір заархівованого зображення (в ) становить приблизно 3 ГБ. ECR Усі зображення зберігаються в Amazon Elastic Container Registry (ECR). Ми використовуємо стандартний тип тома gp3 EBS для вузлів. Виниклі проблеми запуск нового пакета з новим зображенням може зайняти більше 1 години, особливо якщо кілька зображень завантажуються одночасно на одному вузлі. Розширений час холодного запуску: часті помилки або зависання зі станами , що вказує на проблеми з отриманням зображення. Помилки ErrImagePull: ErrImagePull ContainerCreating використання диска залишається майже на 100% під час процесу отримання образу, головним чином через інтенсивний дисковий ввід-вивід, необхідний для декомпресії (наприклад, «unpigz»). Високе використання диска: деякі системні DaemonSets (наприклад, або ) перейшли в стан «не готовий» через тиск на диск, що вплинуло на готовність вузла. Проблеми System DaemonSet: aws-node ebs-csi-node оскільки ми використовуємо точкові екземпляри, ми не можемо використовувати локальний диск для кешування зображень. Немає кешу зображень на вузлах: Це призводить до багатьох зупинених розгортань на гілках функцій, особливо через те, що різні FB мають різні набори базових зображень. Після швидкого дослідження ми виявили, що основною проблемою був тиск диска на вузли через процес . Цей процес відповідає за розпакування зображень докерів. Налаштування за замовчуванням для типу тому gp3 EBS ми не змінювали, тому що не підходять для нашого випадку. unpigz Виправлення для відновлення кластера Як перший крок ми вирішили зменшити кількість POD на вузлах. Переводимо нові вузли в стан «Кордон». Видаліть усі застряглі PODS, щоб зменшити тиск диска Запустіть один за одним POD, щоб розігріти вузли Після цього переводимо розігріті вузли в нормальний стан («без кордону»). Видалено всі вузли в завислому стані Усі POD успішно почали використовувати кеш зображень Docker Оригінальний дизайн CI/CD Основна ідея рішення полягає в тому, щоб розігріти вузли перед початком процесу компакт-диска за допомогою найбільшої частини образу докера (рівня залежностей JS), який використовується як кореневий образ для всіх наших програм. У нас є принаймні 7 типів кореневих зображень із залежностями JS, які пов’язані з типом програми. Отже, давайте розберемо оригінальний дизайн CI/CD. У нашому конвеєрі CI/CD ми маємо 3 стовпи: Оригінальний конвеєр CI/CD: На кроці it: ми готуємо середовище/змінні, визначаємо набір зображень для перебудови тощо... Init На кроці : ми створюємо зображення та надсилаємо їх до ECR Build На кроці : ми розгортаємо образи на k8s (оновлюємо розгортання тощо) Deploy Детальніше про оригінальний дизайн CICD: Наші функціональні гілки (FB) відгалужені від гілки. У процесі CI ми завжди аналізуємо набір зображень, які були змінені у FB, і створюємо їх заново. гілка завжди стабільна, як за визначенням, завжди має бути остання версія базових зображень. main main Ми окремо створюємо образи докерів залежностей JS (для кожного середовища) і надсилаємо їх до ECR, щоб повторно використовувати їх як кореневий (базовий) образ у файлі Docker. У нас є близько 5–10 типів зображень докера залежностей JS. FB розгортається в кластері k8s в окремому просторі імен, але на загальних вузлах для FB. У FB може бути ~200 додатків із розміром зображення до 3 Гб. У нас є система автоматичного масштабування кластера, яка масштабує вузли в кластері на основі завантаження або очікування PODS з відповідним nodeSelector і допуском. Ми використовуємо точкові екземпляри для вузлів. Здійснення процесу розминки Є вимоги до процесу розігріву. Обов'язкові: : розглядає та вирішує проблеми . Вирішення проблеми ContainerCreating : значно скорочується час запуску завдяки використанню попередньо розігрітих базових зображень (залежності JS). Покращена продуктивність Приємно мати покращення: : дозволяє легко змінювати тип вузла та його термін служби (наприклад, високий SLA або подовжений час життя). Гнучкість : надає чіткі показники використання та продуктивності. Прозорість : заощаджує кошти, видаляючи VNG одразу після видалення відповідної гілки функції. Економічність : цей підхід гарантує відсутність впливу на інші середовища. Ізоляція Рішення Проаналізувавши вимоги та обмеження, ми вирішили запровадити процес розігріву, який би попередньо нагрівав вузли базовими зображеннями кешу JS. Цей процес буде запущений до початку процесу CD, гарантуючи, що вузли готові до розгортання FB, і ми матимемо максимальний шанс потрапити в кеш. Це вдосконалення ми розділили на три великих кроки: Створіть (групу віртуальних вузлів) набір вузлів для кожного FB Додайте для нових вузлів базові зображення до сценарію хмарної ініціалізації Додайте із розділом , щоб завантажити необхідні образи докерів на вузли перед початком процесу CD. етап попереднього розгортання, щоб запустити DaemonSet initContainers Оновлений конвеєр CI/CD виглядатиме так: Оновлений конвеєр CI/CD: крок 1.1.(новий крок) : якщо це перший запуск FB, створіть новий особистий набір екземплярів вузлів (у наших термінах це Virtual Node Group або VNG) і завантажте всі базові зображення JS (5–10 зображень). ) від основної гілки. Зробити це цілком справедливо, тому що ми роздвоїли FB з основної гілки. Важливий момент, це не блокуюча операція. Початковий Розгортання ініціалізації Крок нарощування Крок . Завантажте свіжі базові зображення JS із спеціальним тегом FB із ECR. 3.1.(новий крок) : це блокуюча операція, оскільки ми повинні зменшити тиск на диск. Одне за іншим ми завантажуємо базові зображення для кожного пов’язаного вузла. До речі, дякую за крок « , ми вже маємо базові образи докерів з головної гілки, що дає нам великий шанс потрапити в кеш під час першого запуску. перед розгортанням Важливі моменти ініціалізація розгортання» ** Розгорнути **На цьому кроці немає змін. Але завдяки попередньому кроці ми вже маємо всі важкі шари зображень докерів на необхідних вузлах. Ініціалізувати крок розгортання через виклик API (до сторонньої системи автомасштабування) з нашого конвеєра CI. Створіть новий набір вузлів для кожного FB Вирішені проблеми: : кожен FB має власний набір вузлів, що гарантує, що на середовище не впливають інші FB. Ізоляція : ми можемо легко змінити тип вузла та його термін служби. Гнучкість : ми можемо видалити вузли одразу після видалення FB. Економічність : ми можемо легко відстежувати використання та продуктивність вузлів (кожен вузол має тег, пов’язаний із FB). Прозорість : спотовий екземпляр починається з уже визначених базових зображень, тобто після запуску спотового вузла вже є базові зображення на вузлі (з головної гілки). Ефективне використання спотових екземплярів за допомогою сценарію . Завантажте всі базові зображення JS із головної гілки на нові вузли cloud-init Поки зображення завантажуються у фоновому режимі, процес компакт-диска може продовжувати створювати нові зображення без проблем. Крім того, наступні вузли (які будуть створені системою автомасштабування) з цієї групи будуть створені з оновленими даними , які вже містять інструкції для завантаження зображень перед запуском. cloud-init Вирішені проблеми: : навантаження на диск зникло, оскільки ми оновили сценарій , додавши завантаження базових зображень із головної гілки. Це дозволяє нам отримати доступ до кешу під час першого запуску FB. Вирішення проблеми cloud-init : спотовий екземпляр починається з оновлених даних . Це означає, що після запуску спотового вузла на вузлі вже є базові зображення (з головної гілки). Ефективне використання спотових екземплярів cloud-init : процес CD може продовжувати створювати нові образи без проблем. Покращена продуктивність Ця дія додала ~17 секунд (виклик API) до нашого конвеєра CI/CD. Ця дія має сенс лише в перший раз, коли ми запускаємо FB. Наступного разу ми розгорнемо наші програми на вже існуючих вузлах, які вже мають базові образи, які ми доставили під час попереднього розгортання. Крок перед розгортанням Нам потрібен цей крок, оскільки зображення FB відрізняються від зображень основної гілки. Нам потрібно завантажити базові зображення FB на вузли перед початком процесу CD. Це допоможе зменшити подовжений час холодного запуску та високе використання диска, які можуть виникнути, коли одночасно завантажується кілька важких образів. Цілі етапу перед розгортанням : Послідовне завантаження найважчих образів докерів. Після кроку init-deploy ми вже маємо базові зображення на вузлах, що означає, що ми маємо великі шанси отримати кеш звернень. Запобігання тиску на диск : переконайтеся, що вузли попередньо нагріті основними образами докерів, що призведе до швидшого (майже негайного) часу запуску POD. Підвищення ефективності розгортання : мінімізуйте ймовірність виникнення помилок / і переконайтеся, що набори системних демонов залишаються в стані «готовості». Підвищення стабільності ErrImagePull ContainerCreating На цьому кроці ми додаємо 10–15 хвилин до процесу CD. Деталі кроку перед розгортанням: На компакт-диску ми створюємо DaemonSet із розділом . initContainers Розділ виконується перед запуском основного контейнера, забезпечуючи завантаження необхідних зображень до запуску основного контейнера. initContainers На компакт-диску ми постійно перевіряємо стан daemonSet. Якщо daemonSet знаходиться в стані «готовий», ми продовжуємо розгортання. В іншому випадку ми чекаємо, поки daemonSet буде готовий. Порівняння Порівняння вихідного та оновленого етапів із процесом попереднього нагрівання. Крок Ініціалізувати крок розгортання Крок перед розгортанням Розгорнути Загальний час різниця Без попереднього розігріву 0 0 11 хв 21 с 11 хв 21 с 0 З підігрівом 8 секунд 58 секунд 25 секунд 1 хв 31 с -9 хв 50 с Головне, час «Розгортання» змінено (від першої команди застосування до стану запуску модулів) з 11 хвилин 21 секунди до 25 секунд. Загальний час змінився з 11 хв 21 с до 1 хв 31 с. Важливий момент, якщо немає базових зображень з основної гілки, то час «Розгортання» буде таким же, як і вихідний час, або трохи більше. Але все одно ми вирішили проблему з тиском диска і часом холодного старту. Висновок Основну проблему було вирішено шляхом розігріву. В якості переваги ми значно скоротили час холодного запуску POD. Тиск на диск зник, тому що ми вже маємо базові зображення на вузлах. Системні daemonSets перебувають у «готовому» та «справному» стані (оскільки немає тиску на диск), і ми не виявили помилок пов’язаних із цією проблемою. ContainerCreating ErrImagePull Можливі рішення та посилання Використовуйте екземпляри для вузлів замість Ми не можемо використовувати цей спосіб, оскільки це виходить за межі нашого бюджету для невиробничих середовищ. на вимогу спотових екземплярів Ми не можемо використовувати цей спосіб, оскільки ця функція також виходить за рамки нашого бюджету для невиробничих середовищ. Крім того, AWS має th IOPS для вашого облікового запису для кожного регіону. Використовуйте тип обсягу Amazon EBS gp3 (або кращий) зі збільшеним IOPS обмеження Насправді ми не можемо рухатися цим шляхом, оскільки це надто сильно впливає на виробництво та інші середовища, але це також гарне вирішення нашої проблеми. Скоротіть час запуску контейнера на Amazon EKS за допомогою обсягу даних Bottlerocket Усунення несправностей Kubernetes Cluster Autoscaler займає 1 годину, щоб масштабувати 600 модулів я хотів би подякувати чудовій технічній команді ( ) за невтомну роботу та справді творчий підхід до будь-якої проблеми, з якою вони стикаються з. Зокрема, я хочу подякувати Ронні Шарабі, чудовому керівнику, який відповідає за чудову роботу, яку виконує команда. Я з нетерпінням чекаю нових і нових чудових прикладів того, як ваша креативність впливає на продукт Justt. PS: Justt https://www.linkedin.com/company/justt-ai