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

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

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

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

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

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

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

Узгоджені читання з кешу (бета в v1.31)

Хоча API-сервер вже давно використовує кеш для підвищення продуктивності, ключовим етапом стало забезпечення узгоджених читань останніх даних з нього. Це вдосконалення v1.31 дозволило вперше використовувати кеш спостереження для запитів на читання зі строгою узгодженістю, що стало величезним досягненням, оскільки це дозволило безпечно обслуговувати фільтровані колекції (наприклад, "список Podʼів, привʼязаних до цього вузла") з кешу замість 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.

Змінено November 03, 2026 at 6:31 PM PST: [uk] Add blog posts knative-headlamp-plugin, kubernetes-v1-34-snapshottable-api-server-cache and volume-populators-ga (174f2b0be4)