Роками спільнота Kubernetes працює над поліпшенням стабільності та передбачуваності продуктивності сервера API. Основна увага в цих зусиллях була зосереджена на обробці запитів list, які історично були основним джерелом високого використання памʼяті та великого навантаження на сховище etcd. З кожним випуском ми поступово розвʼязували цю проблему, і сьогодні ми раді оголосити про завершення останнього великого етапу цього процесу.
Функція кешу сервера API, що підтримує створення знімків, перейшла в бета-версію в Kubernetes v1.34, що стало кульмінацією зусиль впродовж кількох випусків, спрямованих на те, щоб практично всі запити на читання могли обслуговуватися безпосередньо з кешу сервера API.
Шлях до поточного стану включав кілька ключових вдосконалень у недавніх випусках, які проклали шлях для сьогоднішнього оголошення.
Хоча сервер API вже давно використовує кеш для підвищення продуктивності, ключовим етапом стало забезпечення послідовних читань останніх даних з нього. Це вдосконалення v1.31 дозволило вперше використовувати кеш спостереження для запитів на читання з високою узгодженістю, що стало величезним досягненням, оскільки це дозволило безпечно обслуговувати фільтровані колекції (наприклад, "список подів, привʼязаних до цього вузла") з кешу замість etcd, що різко зменшило навантаження на нього для звичайних робочих навантажень.
Ще одним ключовим вдосконаленням стало вирішення проблеми сплесків памʼяті під час передачі великих відповідей. Потоковий кодувальник, представлений у v1.33, дозволив серверу API надсилати елементи списку по одному, а не буферизувати всю багатогігабайтну відповідь у пам'яті. Це зробило витрати памʼяті на надсилання відповіді передбачуваними та мінімальними, незалежно від її розміру.
Незважаючи на ці величезні вдосконалення, критичний розрив залишався. Будь-який запит на історичний LIST, найчастіше використовуваний для пагінації через великі набори результатів, все ще повинен був обійти кеш і безпосередньо запитати etcd. Це означало, що вартість отримання даних все ще була непередбачуваною і могла створити значний тиск на памʼять сервера API.
Кеш сервера API, що підтримує створення знімків, розвʼязує цю останню частину головоломки. Ця функція покращує кеш спостереження, дозволяючи йому генерувати ефективні, точкові знімки свого стану.
Ось як це працює: для кожного оновлення кеш створює легкий знімок. Ці знімки є "лінивими (lazy) копіями", що означає, що вони не дублюють обʼєкти, а просто зберігають вказівники, що робить їх неймовірно ефективними з точки зору памʼяті.
Коли надходить запит LIST на історичний resourceVersion, сервер API тепер знаходить відповідний знімок і обслуговує відповідь безпосередньо з памʼяті. Це закриває останній великий розрив, дозволяючи обслуговувати запити на пагінацію повністю з кешу.
З цим останнім елементом на місці синергія цих трьох функцій відкриває нову еру передбачуваності та продуктивності сервера API:
Результатом є система, в якій ресурсні витрати на операції читання майже повністю передбачувані і набагато більш стійкі до сплесків навантаження запитів. Це означає різке зменшення тиску на памʼять, менше навантаження на etcd і більш стабільну, масштабовану та надійну панель управління для всіх кластерів Kubernetes.
З моментом переходу в бета-версію функціональність SnapshottableCache є стандартно увімкненою у Kubernetes v1.34. Необхідних дій для початку використання цих покращень продуктивності та стабільності не потрібно.
Особлива подяка за проєктування, впровадження та рецензування цих критичних функцій належить:
… та багато інших у SIG API Machinery. Ця віха є свідченням відданості спільноти побудові більш масштабованого та надійного Kubernetes.