Ця стаття була опублікована більше року тому. Старіші статті можуть містити застарілу інформацію. Перевірте, чи інформація на цій сторінці не втратила актуальності з моменту її публікації.

Kubernetes v1.34: Нова опція статичної політики менеджера CPU для вирівнювання за кешем uncore

Нова опція статичної політики менеджера CPU під назвою prefer-align-cpus-by-uncorecache була представлена в Kubernetes v1.32 як альфа-можливість, а в Kubernetes v1.34 вона перейшла в бета-стадію. Ця опція політики менеджера CPU призначена для оптимізації продуктивності конкретних робочих навантажень, що працюють на процесорах з архітектурою розділеного кешу uncore. У цій статті пояснюється, що це означає і чому це корисно.

Розуміння можливості

Що таке кеш uncore?

До відносно недавнього часу майже всі масові компʼютерні процесори мали монолітний кеш останнього рівня, який ділився між усіма ядрами в багатопроцесорному пакеті. Цей монолітний кеш також називається кешем uncore (оскільки він не повʼязаний з конкретним ядром) або кешем третього рівня. Крім кешу третього рівня, існує інший кеш, який зазвичай називають кешем першого і другого рівня, який повʼязаний з конкретним ядром CPU.

Для зменшення затримки доступу між ядрами CPU та їх кешем нещодавно процесори на базі архітектури AMD64 та ARM впровадили архітектуру розділеного кешу uncore, де кеш останнього рівня ділиться на кілька фізичних кешів, привʼязаних до конкретних груп CPU у фізичному пакеті. Коротші відстані в межах пакета CPU допомагають зменшити затримку.

Діаграма, що показує монолітний кеш зліва і розділений кеш справа

Kubernetes може розміщувати робочі навантаження таким чином, щоб враховувати топологію кешу в межах пакета CPU.

Розміщення робочих навантажень з урахуванням кешу

Матриця нижче показує затримку між CPU, виміряну в наносекундах (менше — краще) при передачі пакета між CPU через протокол когерентності кешу на процесорі, який використовує розділений кеш uncore. У цьому прикладі пакет процесора складається з 2 кешів uncore. Кожен кеш uncore обслуговує 8 ядер CPU.

Таблиця, що показує показники затримки між CPU

Сині елементи в матриці представляють затримку між CPU, які ділять один і той же кеш uncore, тоді як сірі елементи вказують на затримку між CPU, які відповідають різним кешам uncore. Затримка між CPU, які відповідають різним кешам, вища, ніж затримка між CPU, які належать до одного і того ж кешу.

З увімкненим prefer-align-cpus-by-uncorecache, статичний менеджер CPU намагається виділити ресурси CPU для контейнера таким чином, щоб всі CPU, призначені контейнеру, ділили один і той же кеш uncore. Ця політика працює на основі найкращих зусиль, прагнучи мінімізувати розподіл ресурсів CPU контейнера між кешами uncore, виходячи з вимог контейнера та враховуючи ресурси, які можна виділити на вузлі.

Запускаючи робоче навантаження, де це можливо, на наборі CPU, які використовують найменшу можливу кількість кешів uncore, застосунки отримують вигоду від зменшення затримки кешу (як видно з матриці вище) і зменшення конкуренції з іншими робочими навантаженнями, що може призвести до загального підвищення пропускної здатності. Перевага проявляється лише в тому випадку, якщо ваші вузли використовують топологію розділеного кешу uncore для своїх процесорів.

Наступна діаграма ілюструє вирівнювання за кешем uncore, коли можливість увімкнена.

Діаграма, що показує приклад призначення CPU робочому навантаженню, типову статичну політику та політику prefer-align-cpus-by-uncorecache

Типово Kubernetes не враховує топологію кешу uncore; контейнери отримують ресурси CPU за допомогою методології упаковки. Як наслідок, Контейнер 1 і Контейнер 2 можуть зазнати впливу «шумного сусіда» через конкуренцію за доступ до кешу на Uncore Cache 0. Крім того, Контейнер 2 матиме CPU, розподілені між обома кешами, що може призвести до затримки між кешами.

З увімкненим prefer-align-cpus-by-uncorecache, кожен контейнер ізольований на окремому кеші. Це вирішує проблему конкуренції за кеш між контейнерами та мінімізує затримку кешу для використовуваних CPU.

Сценарії використання

Типові сценарії використання можуть включати телекомунікаційні застосунки, такі як vRAN, Mobile Packet Core та брандмауери. Важливо зазначити, що оптимізація, надана prefer-align-cpus-by-uncorecache, може залежати від робочого навантаження. Наприклад, застосунки, обмежені пропускною здатністю памʼяті, можуть не отримати вигоди від вирівнювання за кешем uncore, оскільки використання більшої кількості кешів uncore може збільшити доступ до пропускної здатності памʼяті.

Увімкнення можливості

Щоб увімкнути цю можливість, потрібно встановити політику менеджера CPU на static та увімкнути опцію політики менеджера CPU prefer-align-cpus-by-uncorecache.

Для Kubernetes 1.34 можливість перебуває на стадії бета і вимагає також увімкнення функціональної можливості CPUManagerPolicyBetaOptions.

Додайте таке до файлу конфігурації kubelet:

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
featureGates:
  ...
  CPUManagerPolicyBetaOptions: true
cpuManagerPolicy: "static"
cpuManagerPolicyOptions:
  prefer-align-cpus-by-uncorecache: "true"
reservedSystemCPUs: "0"
...

Якщо ви вносите цю зміну до вже наявного вузла, видаліть файл cpu_manager_state, а потім перезапустіть kubelet.

prefer-align-cpus-by-uncorecache може бути увімкнено на вузлах з монолітним кешем uncore. Ця можливість імітуватиме ефект вирівнювання за сокетами за принципом best-effort та упакує ресурси CPU на сокеті, подібно до типової статичної політики менеджера CPU.

Додаткова інформація

Дивіться статтю Менеджери ресурсів вузлів, щоб дізнатися більше про менеджер CPU та доступні політики.

Ознайомтеся з документацією до prefer-align-cpus-by-uncorecache.

Дивіться Kubernetes Enhancement Proposal для отримання додаткової інформації про те, як реалізовано prefer-align-cpus-by-uncorecache.

Долучайтеся

Ця можливість розробляється SIG Node. Якщо ви зацікавлені в допомозі в розробці цієї можливості, наданні відгуків або участі в будь-яких інших поточних проєктах SIG Node, будь ласка, відвідайте зустріч SIG Node для отримання додаткової інформації.