Kubernetes v1.34: Кеш сервера API, що підтримує створення знімків стану

Автор: Marek Siarkowicz (Google) | Перекладач(і): Андрій Головін |

Роками спільнота Kubernetes працює над поліпшенням стабільності та передбачуваності продуктивності сервера API. Основна увага в цих зусиллях була зосереджена на обробці запитів list, які історично були основним джерелом високого використання памʼяті та великого навантаження на сховище etcd. З кожним випуском ми поступово розвʼязували цю проблему, і сьогодні ми раді оголосити про завершення останнього великого етапу цього процесу.

Функція кешу сервера API, що підтримує створення знімків, перейшла в бета-версію в Kubernetes v1.34, що стало кульмінацією зусиль впродовж кількох випусків, спрямованих на те, щоб практично всі запити на читання могли обслуговуватися безпосередньо з кешу сервера API.

Еволюція кешу для продуктивності та стабільності

Шлях до поточного стану включав кілька ключових вдосконалень у недавніх випусках, які проклали шлях для сьогоднішнього оголошення.

Послідовні читання з кешу (бета в v1.31)

Хоча сервер API вже давно використовує кеш для підвищення продуктивності, ключовим етапом стало забезпечення послідовних читань останніх даних з нього. Це вдосконалення v1.31 дозволило вперше використовувати кеш спостереження для запитів на читання з високою узгодженістю, що стало величезним досягненням, оскільки це дозволило безпечно обслуговувати фільтровані колекції (наприклад, "список подів, привʼязаних до цього вузла") з кешу замість etcd, що різко зменшило навантаження на нього для звичайних робочих навантажень.

Упорядкування великих відповідей за допомогою потокової передачі (бета в v1.33)

Ще одним ключовим вдосконаленням стало вирішення проблеми сплесків памʼяті під час передачі великих відповідей. Потоковий кодувальник, представлений у v1.33, дозволив серверу API надсилати елементи списку по одному, а не буферизувати всю багатогігабайтну відповідь у пам'яті. Це зробило витрати памʼяті на надсилання відповіді передбачуваними та мінімальними, незалежно від її розміру.

Відсутня частина

Незважаючи на ці величезні вдосконалення, критичний розрив залишався. Будь-який запит на історичний LIST, найчастіше використовуваний для пагінації через великі набори результатів, все ще повинен був обійти кеш і безпосередньо запитати etcd. Це означало, що вартість отримання даних все ще була непередбачуваною і могла створити значний тиск на памʼять сервера API.

Kubernetes 1.34: створення знімків довершує картину

Кеш сервера API, що підтримує створення знімків, розвʼязує цю останню частину головоломки. Ця функція покращує кеш спостереження, дозволяючи йому генерувати ефективні, точкові знімки свого стану.

Ось як це працює: для кожного оновлення кеш створює легкий знімок. Ці знімки є "лінивими (lazy) копіями", що означає, що вони не дублюють обʼєкти, а просто зберігають вказівники, що робить їх неймовірно ефективними з точки зору памʼяті.

Коли надходить запит LIST на історичний resourceVersion, сервер API тепер знаходить відповідний знімок і обслуговує відповідь безпосередньо з памʼяті. Це закриває останній великий розрив, дозволяючи обслуговувати запити на пагінацію повністю з кешу.

Нова ера продуктивності сервера API 🚀

З цим останнім елементом на місці синергія цих трьох функцій відкриває нову еру передбачуваності та продуктивності сервера API:

  1. Отримання даних з кешу: Послідовні читання та кеш, що підтримує створення знімків, працюють разом, щоб забезпечити обслуговування майже всіх запитів на читання, незалежно від того, чи йдеться про останні дані або історичний знімок, безпосередньо з памʼяті сервера API.
  2. Надсилання даних через потік: Потокова передача спискових відповідей забезпечує мінімальний і постійний обсяг памʼяті при відправці цих даних клієнту.

Результатом є система, в якій ресурсні витрати на операції читання майже повністю передбачувані і набагато більш стійкі до сплесків навантаження запитів. Це означає різке зменшення тиску на памʼять, менше навантаження на etcd і більш стабільну, масштабовану та надійну панель управління для всіх кластерів Kubernetes.

Як почати

З моментом переходу в бета-версію функціональність SnapshottableCache є стандартно увімкненою у Kubernetes v1.34. Необхідних дій для початку використання цих покращень продуктивності та стабільності не потрібно.

Подяки

Особлива подяка за проєктування, впровадження та рецензування цих критичних функцій належить:

… та багато інших у SIG API Machinery. Ця віха є свідченням відданості спільноти побудові більш масштабованого та надійного Kubernetes.