Суперечливість використання процесора Kubernetes та метрики Docker Container

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

• Агенти DataDog, що працюють як Daemonset
• Існуючі програми, що працюють без обмежень процесора
• Контейнери - це багатопотокові додатки Ruby
• Дві показники: kubernetes.cpu.usage.{avg,max}іdocker.cpu.usage
• c4.xlarge кластерні вузли (4 vCPU або 4000m в Кубернеті)

kubernetes.cpu.usage.maxзвіти ~ 600м для відповідних контейнерів. docker.cpu.usageзвіти ~ 60%. Звідси випливає, що обмеження процесора в 1000 м було б більш ніж достатньою ємністю при нормальній роботі.

Я встановив межу в 1000м. Потім docker.container.throttlesістотно піднімається вгору kubernetes.cpu.usage.maxі docker.cpu.usageзалишається таким же. У цей час система все опускається на коліна. Це для мене немає сенсу.

Я досліджував статистику Докера. Здається, що docker stats(і базовий API) нормалізують навантаження відповідно до ядер CPU. Тож у моєму випадку docker.cpu.usageвід 60% припадає (4000м * 0,60) до 2400м у Кубернеті. Однак це не співвідноситься з жодними номерами Кубернетів. Я зробив ще один експеримент, щоб перевірити свою гіпотезу про те, що числа Кубернета є невірними. Я встановив обмеження в 2600 м (для деякого додаткового запасу). Це не призвело до жодних дроселів. Однак Kubernetes спостерігав, що використання процесора не змінилося. Це залишає мене розгубленим.

Отже, мої запитання:

• Це відчувається як помилка в Kubernetes (чи щось у стеці?)
• Чи правильно моє розуміння?

Моє наступне питання стосується того, як правильно визначити процесор для додатків Ruby. В одному контейнері використовується Puma. Це багатопотоковий веб-сервер з налаштованою кількістю потоків. HTTP-запити обробляються одним із потоків. Друга програма - ощадливий сервер, що використовує потоковий сервер. Кожне вхідне TCP-з'єднання обробляється власним потоком. Потік виходить, коли з'єднання закривається. Ruby як GIL (Global Interpreter Lock), тож лише один потік може одночасно виконувати код Ruby. Це дає змогу виконувати декілька потоків вводу-виводу тощо.

Я вважаю, що найкращим підходом є обмеження кількості потоків, що виконуються в кожній програмі, та наближення обмежень процесора Kubernetes на основі кількості потоків. Процеси не формуються, тому загальне використання процесора передбачити важче.

Тут питання: як правильно передбачити використання процесора та ліміти цих програм?

Тут є кілька речей:

1. Ви на AWS ec2, отже, все, що ви робите у вашому екземплярі для вимірювання CPU - це обчислення CPU на рівні гіпервізора, а не на рівні екземпляра. Для цього просто запустіть будь-який тест навантаження та перевірте використання iostat -ct 1 та використання центрального процесора у хмарному годиннику. Використання процесора у хмарному годиннику завжди на 10-20% більше, ніж те, про що повідомить iostat, і це тому, що iostat дасть використання процесора на рівні гіпервізора.

2. Як докер бачити, як порівнюють показники кубернетів та докерних показників, я пропоную запустити контейнери з --cpuset = 1 або будь-яким числом, щоб всі контейнери могли використовувати лише один vCPU.

3. Також в AWS 1 CPU = 2vcpu. Це гіпертоковано до 2. Ви можете це врахувати під час розрахунку.

4. Нарешті, найкращий показник, який використовується для перегляду використання процесора для певного додатка, - це використання htop та співвіднесення з показниками хмарного перегляду.

5. Я також спостерігав, що інколи демон докера прив'язує себе до одного з віртуальних процесорів, і, отже, коли ви зменшуєте його до 1000 м, можливо, вся настройка стає повільною, оскільки зменшення відбувається на будь-якому з vpcus. Ви можете використовувати mpstat, щоб отримати детальну інформацію про це.

6. Нарешті, на рівні хоста ви можете прив’язати докер до одного процесора та спостерігати більше.

Сподіваюся, це зблизить вас. Оновіть мене, якщо ви вже знайшли рішення.