Kubernetes Blog

Що потрібно знати перед міграцією: пʼять несподіваних особливостей поведінки Ingress-NGINX

Fri, 27 Feb 2026 07:30:00 -0800

Як було оголошено в листопаді 2025 року, Kubernetes припинить підтримку Ingress-NGINX у березні 2026 року. Незважаючи на широке використання, Ingress-NGINX має безліч несподіваних стандартних налаштувань і побічних ефектів, які, ймовірно, присутні у вашому кластері зараз. У цьому дописі описано ці особливості, щоб ви могли безпечно здійснити міграцію та свідомо вирішити, які з них зберегти. У дописі також порівнюється Ingress-NGINX та Gateway API і показано, як зберегти особливості Ingress-NGINX у Gateway API. Ризик, що повторюється в кожному розділі, є однаковим: на перший погляд правильно виконане перетворення все одно може спричинити перебої в роботі, якщо не врахувати особливості Ingress-NGINX.

Я припускаю, що ви, читачі, маєте певне уявлення про Ingress-NGINX та Ingress API. У більшості прикладів як бекенд використовується httpbin.

Також зверніть увагу, що Ingress-NGINX і NGINX Ingress — це два окремі контролери Ingress. Ingress-NGINX — це контролер Ingress, який підтримується та керується спільнотою Kubernetes і який буде виведений з експлуатації в березні 2026 року. NGINX Ingress — це контролер Ingress від F5. Обидва використовують NGINX як рівень обробки даних, але в іншому не повʼязані між собою. Відтепер у цій публікації ми будемо обговорювати лише Ingress-NGINX.

1. Збіги регулярних виразів базуються на префіксах і не чутливі до регістру

Припустимо, ви хочете перенаправити всі запити зі шляхом, що складається лише з трьох великих літер, до сервісу httpbin. Ви можете створити наступний Ingress з анотацією nginx.ingress.kubernetes.io/use-regex: "true" annotation and the regex pattern of /[A-Z]{3}.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: regex-match-ingress
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: regex-match.example.com
    http:
      paths:
      - path: "/[A-Z]{3}"
        pathType: ImplementationSpecific
        backend:
          service:
            name: httpbin
            port:
              number: 8000

Однак, оскільки регулярні вирази не враховують префікси та регістр, Ingress-NGINX перенаправляє будь-який запит із шляхом, що починається з будь-яких трьох літер, на httpbin:

curl -sS -H "Host: regex-match.example.com" http://<your-ingress-ip>/uuid

Результат буде схожим на:

{
  "uuid": "e55ef929-25a0-49e9-9175-1b6e87f40af7"
}

Примітка: Точка доступу /uuid httpbin повертає випадковий UUID. UUID у тілі відповіді означає, що запит був успішно перенаправлений до httpbin.

За допомогою Gateway API ви можете використовувати HTTP path match з type типу RegularExpression для зіставлення шляхів за регулярним виразом. Зіставлення RegularExpression залежать від конкретної реалізації, тому перевірте реалізацію Gateway API, щоб переконатися в семантиці зіставлення RegularExpression. Популярні реалізації Gateway API на основі Envoy, такі як Istio¹, Envoy Gateway та Kgateway, виконують повне співставлення з урахуванням регістру.

Отже, якщо ви не знаєте, що шаблони Ingress-NGINX є префіксами і не чутливі до регістру, і, не знаючи про це, клієнти або застосунки надсилають трафік до /uuid (або /uuid/some/other/path), ви можете створити такий маршрут HTTP.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: regex-match-route
spec:
  hostnames:
  - regex-match.example.com
  parentRefs:
  - name: <your gateway>  # Змінюйте це залежно від вашого випадку використання
  rules:
  - matches:
    - path:
        type: RegularExpression
        value: "/[A-Z]{3}"
    backendRefs:
    - name: httpbin
      port: 8000

Однак, якщо ваша реалізація Gateway API виконує повне співставлення з урахуванням регістру, вищевказаний маршрут HTTP не буде відповідати запиту зі шляхом /uuid. Таким чином, вищевказаний маршрут HTTP спричинить збій, оскільки запити, які Ingress-NGINX маршрутизував до httpbin, завершаться з помилкою 404 Not Found на шлюзі.

Щоб зберегти співставлення регулярних виразів без урахування регістру, ви можете використовувати наступний маршрут HTTP.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: regex-match-route
spec:
  hostnames:
  - regex-match.example.com
  parentRefs:
  - name: <your gateway>  # Змінюйте це залежно від вашого випадку використання
  rules:
  - matches:
    - path:
        type: RegularExpression
        value: "/[a-zA-Z]{3}.*"
    backendRefs:
    - name: httpbin
      port: 8000

Крім того, вищезазначені проксі підтримують прапорець (?i) для позначення збігів, нечутливих до регістру. Використовуючи цей прапорець, шаблон може бути таким: (?i)/[a-z]{3}.*.

2. `nginx.ingress.kubernetes.io/use-regex` застосовується до всіх шляхів хоста у всіх (Ingress-NGINX) Ingresses

Тепер припустимо, що у вас є Ingress з анотацією nginx.ingress.kubernetes.io/use-regex: "true", але ви хочете маршрутизувати запити з шляхом /headers до httpbin. На жаль, ви зробили помилку і встановили шлях /Header замість /headers.

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: regex-match-ingress
  annotations:
    nginx.ingress.kubernetes.io/use-regex: "true"
spec:
  ingressClassName: nginx
  rules:
  - host: regex-match.example.com
    http:
      paths:
      - path: "<some regex pattern>"
        pathType: ImplementationSpecific
        backend:
          service:
            name: <your backend>
            port:
              number: 8000
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: regex-match-ingress-other
spec:
  ingressClassName: nginx
  rules:
  - host: regex-match.example.com
    http:
      paths:
      - path: "/Header" # тут помилка, має бути /headers
        pathType: Exact
        backend:
          service:
            name: httpbin
            port:
              number: 8000

Більшість очікує, що запит до /headers поверне відповідь 404 Not Found, оскільки /headers не відповідає Exact шляху /Header. Однак, оскільки Ingress regex-match-ingress має анотацію nginx.ingress.kubernetes.io/use-regex: "true" і хост regex-match.example.com, всі шляхи з хостом regex-match.example.com розглядаються як регулярні вирази у всіх (Ingress-NGINX) Ingress. Оскільки шаблони регулярних виразів є префіксними збігами, що не чутливі до регістру, /headers збігається з шаблоном /Header, і Ingress-NGINX маршрутизує такі запити до httpbin. Виконання команди

curl -sS -H "Host: regex-match.example.com" http://<your-ingress-ip>/headers

дасть наступний результат:

{
  "headers": {
    ...
  }
}

Примітка: Точка доступу /headers httpbin повертає заголовки запиту. Те, що відповідь містить заголовки запиту в тілі, означає, що запит був успішно перенаправлений на httpbin.

Gateway API не перетворює і не інтерпретує збіги Exact і Prefix як шаблони регулярних виразів. Тому, якщо ви перетворили вищезазначені Ingresses у наступний маршрут HTTP і зберегли типи помилок і збігів, запити до /headers будуть відповідати кодом 404 Not Found замість 200 OK.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: regex-match-route
spec:
  hostnames:
  - regex-match.example.com
  rules:
  ...
  - matches:
    - path:
        type: Exact
        value: "/Header"
    backendRefs:
    - name: httpbin
      port: 8000

Щоб зберегти відповідність префіксів без врахування регістру, можна змінити

  - matches:
    - path:
        type: Exact
        value: "/Header"

на

  - matches:
    - path:
        type: RegularExpression
        value: "(?i)/Header"

А ще краще, ви могли б виправити помилку і змінити шаблон на

  - matches:
    - path:
        type: Exact
        value: "/headers"

3. Переписування цільового обʼєкта передбачає використання регулярного виразу

У цьому випадку припустимо, що ви хочете переписати шлях запитів із /ip на /uuid перед їх маршрутизацією до httpbin, і, як у розділі 2, ви хочете маршрутизувати запити із шляхом /headers до httpbin. Однак ви випадково зробили помилку і встановили шлях /IP замість /ip і /Header замість /headers.

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-target-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: "/uuid"
spec:
  ingressClassName: nginx
  rules:
  - host: rewrite-target.example.com
    http:
      paths:
      - path: "/IP"
        pathType: Exact
        backend:
          service:
            name: httpbin
            port:
              number: 8000
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: rewrite-target-ingress-other
spec:
  ingressClassName: nginx
  rules:
  - host: rewrite-target.example.com
    http:
      paths:
      - path: "/Header"
        pathType: Exact
        backend:
          service:
            name: httpbin
            port:
              number: 8000

Анотація nginx.ingress.kubernetes.io/rewrite-target: «/uuid» призводить до того, що запити, які відповідають шляхам в Ingress rewrite-target-ingress, мають свої шляхи перетворені на /uuid перед тим, як бути перенаправленими на бекенд.

Незважаючи на те, що жоден Ingress не має анотації nginx.ingress.kubernetes.io/use-regex: "true", наявність анотації nginx.ingress.kubernetes.io/rewrite-target в Ingress rewrite-target-ingress призводить до того, що всі шляхи з хостом rewrite-target.example.com розглядаються як шаблони регулярних виразів. Іншими словами, nginx.ingress.kubernetes.io/rewrite-target тихо додає анотацію nginx.ingress.kubernetes.io/use-regex: "true", разом з усіма побічними ефектами, описаними вище.

Наприклад, шлях запиту до /ip перезаписується на /uuid, оскільки /ip відповідає префіксу /IP, що не чутливий до регістру, в Ingress rewrite-target-ingress. Після виконання команди

curl -sS -H "Host: rewrite-target.example.com" http://<your-ingress-ip>/ip

результат буде схожим на:

{
  "uuid": "12a0def9-1adg-2943-adcd-1234aadfgc67"
}

Як і в прикладі nginx.ingress.kubernetes.io/use-regex, Ingress-NGINX обробляє path інших інгресів з хостом rewrite-target.example.com як префіксні шаблони, що не розрізняють регістр. Виконання команди

curl -sS -H "Host: rewrite-target.example.com" http://<your-ingress-ip>/headers

дає результат, який виглядає так

{
  "headers": {
    ...
  }
}

Ви можете налаштувати перезапис шляхів у Gateway API за допомогою фільтра перезапису HTTP URL, який не перетворює ваші збіги Exact та Prefix у шаблони регулярних виразів. Однак, якщо ви не знаєте про побічні ефекти анотації nginx.ingress.kubernetes.io/rewrite-target і не розумієте, що /Header і /IP є помилками, ви можете створити такий маршрут HTTP.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: rewrite-target-route
spec:
  hostnames:
  - rewrite-target.example.com
  parentRefs:
  - name: <your-gateway>
  rules:
  - matches:
    - path:
        type: Exact
        value: "/IP"
    filters:
    - type: URLRewrite
      urlRewrite:
        path:
          type: ReplaceFullPath
          replaceFullPath: /uuid
    backendRefs:
    - name: httpbin
      port: 8000
  - matches:
    - path:
        # Це точне співпадіння, незалежно від інших правил.
        type: Exact
        value: "/Header"
    backendRefs:
    - name: httpbin
      port: 8000

Як і в розділі 2, оскільки /IP тепер є типом збігу Exact у вашому маршруті HTTP, запити до /ip будуть відповідати кодом 404 Not Found замість 200 OK. Аналогічно, запити до /headers також будуть відповідати кодом 404 Not Found замість 200 OK. Таким чином, цей маршрут HTTP порушить роботу застосунків і клієнтів, які покладаються на маршрути /ip і /headers.

Щоб виправити це, ви можете змінити збіги в маршруті HTTP на збіги регулярних виразів і змінити шаблони шляхів на збіги префіксів, що не чутливі до регістру, як показано нижче.

  - matches:
    - path:
        type: RegularExpression
        value: "(?i)/IP.*"
...
  - matches:
    - path:
        type: RegularExpression
        value: "(?i)/Header.*"

Або ви можете залишити тип збігу Exact і виправити помилки.

4. Запити, в яких відсутній кінцевий слеш, перенаправляються на той самий шлях з кінцевим слешем

Розглянемо наступний Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: trailing-slash-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: trailing-slash.example.com
    http:
      paths:
      - path: "/my-path/"
        pathType: Exact
        backend:
          service:
            name: <your-backend>
            port:
              number: 8000

Ви можете очікувати, що Ingress-NGINX відповість на /my-path кодом 404 Not Found, оскільки /my-path не збігається з Exact шляхом /my-path/. Однак Ingress-NGINX перенаправляє запит на /my-path/ з кодом 301 Moved Permanently, оскільки єдина відмінність між /my-path і /my-path/ — це кінцевий слеш.

curl -isS -H "Host: trailing-slash.example.com" http://<your-ingress-ip>/my-path

Результат виглядає так:

HTTP/1.1 301 Moved Permanently
...
Location: http://trailing-slash.example.com/my-path/
...

Те саме стосується випадків, коли ви змінюєте pathType на Prefix. Однак перенаправлення не відбувається, якщо шлях є шаблоном регулярного виразу.

Сумісні реалізації Gateway API не конфігурують жодних перенаправлень без попередження. Якщо клієнти або сервіси нижчого рівня залежать від цього перенаправлення, міграція до Gateway API, який не конфігурує перенаправлення запитів явно, спричинить збій, оскільки запити до /my-path тепер будуть відповідати кодом 404 Not Found замість 301 Moved Permanently. Ви можете явно налаштувати перенаправлення за допомогою фільтра перенаправлення HTTP-запитів наступним чином:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: trailing-slash-route
spec:
  hostnames:
  - trailing-slash.example.com
  parentRefs:
  - name: <your-gateway>
  rules:
  - matches:
    - path:
        type: Exact
        value: "/my-path"
    filters:
      requestRedirect:
        statusCode: 301
        path:
          type: ReplaceFullPath
          replaceFullPath: /my-path/
  - matches:
    - path:
        type: Exact # або Prefix
        value: "/my-path/"
    backendRefs:
    - name: <your-backend>
      port: 8000

5. Ingress-NGINX нормалізує URL-адреси

Нормалізація URL-адреси — це процес перетворення URL-адреси в канонічну форму перед її зіставленням з правилами Ingress і маршрутизацією. Особливості нормалізації URL-адреси визначені в RFC 3986, розділ 6.2, але ось декілька прикладів

видалення сегментів шляху, які є лише .: my/./path -> my/path
сегмент шляху .. видаляє попередній сегмент: my/../path -> /path
видалення послідовних косих рисок у шляху: my//path -> my/path

Ingress-NGINX нормалізує URL-адреси перед їх порівнянням з правилами Ingress. Наприклад, розглянемо наступний Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: path-normalization-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: path-normalization.example.com
    http:
      paths:
      - path: "/uuid"
        pathType: Exact
        backend:
          service:
            name: httpbin
            port:
              number: 8000

Ingress-NGINX нормалізує шлях наступних запитів до /uuid. Тепер, коли запит відповідає шляху Exact /uuid, Ingress-NGINX відповідає або кодом 200 OK, або кодом 301 Moved Permanently до /uuid.

Для наступних команд

curl -sS -H "Host: path-normalization.example.com" http://<your-ingress-ip>/uuid
curl -sS -H "Host: path-normalization.example.com" http://<your-ingress-ip>/ip/abc/../../uuid
curl -sSi -H "Host: path-normalization.example.com" http://<your-ingress-ip>////uuid

результати схожі на

{
  "uuid": "29c77dfe-73ec-4449-b70a-ef328ea9dbce"
}

{
  "uuid": "d20d92e8-af57-4014-80ba-cf21c0c4ffae"
}

HTTP/1.1 301 Moved Permanently
...
Location: /uuid
...

Ваші бекенди можуть покладатися на реалізацію API Ingress/Gateway для нормалізації URL-адрес. При цьому більшість реалізацій API Gateway мають стагжартно увімкнену функцію нормалізації шляхів. Наприклад, Istio, Envoy Gateway та Kgateway нормалізують сегменти . та .. без додаткових налаштувань. Для отримання детальнішої інформації перегляньте документацію для кожної реалізації API Gateway, яку ви використовуєте.

Підсумок

Оскільки ми всі поспішаємо реагувати на виведення з експлуатації Ingress-NGINX, сподіваюся, що ця публікація додасть вам впевненості в тому, що ви зможете безпечно та ефективно здійснити міграцію, незважаючи на всі складнощі Ingress-NGINX.

SIG Network також працює над підтримкою найпоширеніших анотацій Ingress-NGINX (та деяких несподіваних поведінок) в Ingress2Gateway, щоб допомогти вам перетворити конфігурацію Ingress-NGINX на Gateway API та запропонувати альтернативи для непідтримуваних поведінок.

SIG Network випустила Gateway API 1.5 сьогодні (27 лютого 2026 року), яка вдосконалює такі функції, як ListenerSet (що дозволяє розробникам додатків краще управляти сертифікатами TLS) та фільтр HTTPRoute CORS, що дозволяє конфігурувати CORS.

Ви можете використовувати Istio виключно як контролер Gateway API без інших функцій сервісної мережі. ↩︎

Представляємо контролер готовності вузлів

Tue, 03 Feb 2026 10:00:00 +0800

У стандартній моделі Kubernetes придатність вузла для робочих навантажень залежить від єдиного бінарного стану «Ready» («Готовий»). Однак у сучасних середовищах Kubernetes вузли потребують складних інфраструктурних залежностей, таких як мережеві агенти, драйвери сховищ, прошивка GPU або спеціальні перевірки працездатності, щоб бути повністю готовими до роботи, перш ніж вони зможуть надійно обслуговувати поди.

Сьогодні від імені проєкту Kubernetes я оголошую про запуск Node Readiness Controller. Цей проєкт впроваджує декларативну систему для управління позначками вузлів, розширюючи захисні барʼєри готовності під час завантаження вузлів за межі стандартних станів. Динамічно керуючи taints на основі спеціальних сигналів стану, контролер гарантує, що робочі навантаження розміщуються тільки на вузлах, які відповідають усім вимогам інфраструктури.

Навіщо потрібен контролер готовності вузлів?

Основний статус «Ready» вузлів Kubernetes часто є недостатнім для кластерів із складними вимогами до ініціалізації. Оператори часто стикаються з труднощами, намагаючись переконатися, що певні DaemonSets або локальні сервіси працюють належним чином, перш ніж вузол потрапить до пулу планування.

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

Він надає три основні переваги:

Налаштовані визначення готовності: визначте, що означає готовий для вашої конкретної платформи.
Автоматизоване управління позначками: контролер автоматично застосовує або видаляє позначки taint вузлів на основі стану, запобігаючи потраплянню подів на непідготовлену інфраструктуру.
Декларативна ініціалізація вузлів: надійно керуйте багатоетапною ініціалізацією вузлів із чітким спостереженням за процесом ініціалізації.

Основні поняття та функції

Контролер базується на API NodeReadinessRule (NRR), який дозволяє визначати декларативні gate для ваших вузлів.

Гнучкі режими виконання

Контролер підтримує два різних режими роботи:

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

Звіт про стан

Контролер реагує на стан вузлів, а не виконує перевірки працездатності самостійно. Така роздільна конструкція дозволяє йому безперешкодно інтегруватися з іншими інструментами, що існують в екосистемі, а також з індивідуальними рішеннями:

Node Problem Detector (NPD): використовуйте наявні налаштування NPD та власні скрипти для звітування про стан вузлів.
Readiness Condition Reporter: легкий агент, наданий проєктом, який можна розгорнути для періодичної перевірки локальних HTTP точок доступу та відповідного виправлення стану вузлів.

Операційна безпека з тестовим запуском

Впровадження нових правил готовності у всьому парку обладнання несе в собі певний ризик. Щоб його зменшити, режим тестового запуску (dry run) дозволяє операторам спочатку змоделювати вплив на кластер. У цьому режимі контролер реєструє заплановані дії та оновлює статус правила, щоб показати вузли, на які це вплине, без застосування фактичних позначок taint, що дозволяє безпечно перевірити правило перед його впровадженням.

Приклад: ініціалізація CNI

Наступне правило NodeReadinessRule гарантує, що вузол залишатиметься таким, що не підлягає плануванню, доки його агент CNI не почне функціонувати. Контролер відстежує спеціальну умову cniplugin.example.net/NetworkReady і видаляє позначку readiness.k8s.io/acme.com/network-unavailable лише тоді, коли статус стає True.

apiVersion: readiness.node.x-k8s.io/v1alpha1
kind: NodeReadinessRule
metadata:
  name: network-readiness-rule
spec:
  conditions:
    - type: "cniplugin.example.net/NetworkReady"
      requiredStatus: "True"
  taint:
    key: "readiness.k8s.io/acme.com/network-unavailable"
    effect: "NoSchedule"
    value: "pending"
  enforcementMode: "bootstrap-only"
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker: ""

Демо:

Приєднуйтесь

Node Readiness Controller тільки починає свою роботу, і ми випустили перші версії [https://github.com/kubernetes-sigs/node-readiness-controller/releases/tag/v0.1.1). Зараз ми чекаємо на відгуки від спільноти, щоб вдосконалити план розвитку. Після плідних дискусій на Unconference під час KubeCon NA 2025 ми з радістю продовжимо розмову віч-на-віч.

Приєднуйтесь до нас на KubeCon + CloudNativeCon Europe 2026 на сесії для розробників: Вирішення проблеми недетермінованого планування: представлення Node Readiness Controller.

Тим часом ви можете долучитися до нашої роботи або стежити за нашими досягненнями тут:

GitHub: https://sigs.k8s.io/node-readiness-controller
Slack: долучіться до обговорення в #sig-node-readiness-controller
Документація: Початок роботи

Нове перетворення з cgroup v1 CPU Shares на v2 CPU Weight

Fri, 30 Jan 2026 08:00:00 -0800

Я радий повідомити про впровадження вдосконаленої формули перетворення з cgroup v1 CPU shares на cgroup v2 CPU weight. Це вдосконалення вирішує критичні проблеми з розподілом пріоритетів CPU для робочих навантажень Kubernetes під час роботи на системах з cgroup v2.

Історія

Kubernetes спочатку був розроблений з урахуванням cgroup v1, де CPU shares визначалися просто шляхом присвоєння контейнеру CPU-запитів у вигляді millicpu.

Наприклад, контейнер, що запитує 1 CPU (1024m) отримає (cpu.shares = 1024).

Через деякий час почалася заміна cgroup v1 на його наступника, cgroup v2. У cgroup v2 концепція частки процесора (яка коливається від 2 до 262144, або від 2¹ до 2¹⁸) була замінена CPU weight (яка коливається від [1, 10000], або від 10⁰ до 10⁴).

З переходом на cgroup v2, KEP-2254 впровадив формулу перетворення для зіставлення cgroup v1 CPU shares з cgroup v2 CPU weight. Формула перетворення була визначена як: cpu.weight = (1 + ((cpu.shares - 2) * 9999) / 262142)

Ця формула лінійно співвідносить значення від [2¹, 2¹⁸] до [10⁰, 10⁴].

Хоча цей підхід є простим, лінійне співвідношення створює кілька значних проблем і впливає як на продуктивність, так і на ступінь деталізації конфігурації.

Проблеми з попередньою формулою перетворення

Поточна формула перетворення створює дві основні проблеми:

1. Зниження пріоритету порівняно з робочими навантаженнями, що не належать до Kubernetes

У cgroup v1 стандартне значення для розподілу ресурсів процесора становить 1024, що означає, що контейнер, який запитує 1 процесор, має такий самий пріоритет, як і системні процеси, що знаходяться поза межами Kubernetes. Однак у cgroup v2 CPU weight у стандартних налаштуваннях становить 100, але поточна формула перетворює 1 CPU (1024m) лише на ≈39 weight — менше ніж 40 % від стандартного значення.

Приклад:

Контейнер, що запитує 1 CPU (1024m)
cgroup v1: cpu.shares = 1024 (дорівнює стандартному значенню)
cgroup v2 (поточний): cpu.weight = 39 (значно нижче за стандартне значення 100)

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

2. Некерована деталізація

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

Приклад:

Контейнер, що запитує 100m CPU
cgroup v1: cpu.shares = 102
cgroup v2 (поточна): cpu.weight = 4 (занадто низьке значення для конфігурації підгруп cgroup)

З cgroup v1 запит на 100m CPU, що призвів до 102 CPU shares, був керованим у тому сенсі, що підгрупи cgroup могли бути створені всередині основного контейнера, призначаючи детальні пріоритети CPU для різних груп процесів. Однак з cgroup v2 дуже важко розподілити 4 shares між підгрупами cgroup, оскільки це недостатньо детально.

З планами дозволити записувані cgroups для контейнерів без привілеїв, це стає ще більш актуальним.

Нова формула перетворення

Опис

Нова формула є більш складною, але набагато краще відображає ‍ співвідношення між cgroup v1 CPU shares та cgroup v2 CPU weight:

$$cpu.weight = \lceil 10^{(L^{2}/612 + 125L/612 - 7/34)} \rceil, \text{ де: } L = \log_2(cpu.shares)$$

Ідея полягає в тому, що це квадратична функція, яка перетинає наступні значення:

(2, 1): мінімальні значення для обох діапазонів.
(1024, 100): стандартні значення для обох діапазонів.
(262144, 10000): максимальні значення для обох діапазонів.

Візуально нова функція виглядає наступним чином:

А якщо збільшити важливу частину:

Нова формула є «майже лінійною», проте вона ретельно розроблена для розумного зіставлення діапазонів, щоб три важливі точки, зазначені вище, перетиналися.

Як це розвʼязує проблеми

Кращя узгодженість пріоритетів:
- Контейнер, що запитує 1 CPU (1024m) тепер отримає cpu.weight = 102. Це значення близьке до стандартного значення 100 в cgroup v2. Це відновлює передбачуване співвідношення пріоритетів між робочими навантаженнями Kubernetes і системними процесами.
Покращена деталізація:
- Контейнер, що запитує 100m CPU, отримає cpu.weight = 17, (дивіться тут). Це дозволяє краще розподіляти ресурси в контейнерах.

Впровадження та інтеграція

Ця зміна була впроваджена на рівні OCI. Іншими словами, вона не впроваджена в самому Kubernetes, тому впровадження нової формули перетворення залежить виключно від впровадження OCI runtime.

Наприклад:

runc: нова формула увімкнена з версії 1.3.2.
crun: нова формула увімкнена з версії 1.23.

Вплив на наявні розгортання

Важливо: Деякі споживачі можуть зазнати впливу, якщо вони використовують стару лінійну формулу перетворення. Застосування або інструменти моніторингу, які безпосередньо обчислюють очікувані значення CPU weight на основі попередньої формули, можуть потребувати оновлення, щоб врахувати нове квадратичне перетворення. Це особливо актуально для:

Настроюваних інструментів управління ресурсами, які прогнозують значення CPU weight.
Систем моніторингу, які перевіряють або очікують конкретні значення ваги.
Застосунків, які програмно встановлюють або перевіряють значення CPU weight.

У рамках проєкту Kubernetes рекомендується протестувати нову формулу перетворення в тестових середовищах перед оновленням OCI runtimes, щоб забезпечити сумісність з наявними інструментами.

Де можна дізнатися більше?

Для тих, хто цікавиться цим вдосконаленням:

Kubernetes GitHub Issue #131216 — Докладний технічний аналіз і приклади, включаючи обговорення та обґрунтування вибору вищезазначеної формули.
KEP-2254: cgroup v2 — Оригінальна реалізація cgroup v2 в Kubernetes.
Документація Kubernetes cgroup — Поточні рекомендації щодо управління ресурсами.

Як долучитися?

Якщо ви зацікавлені у розробці функцій на рівні вузлів Kubernetes, приєднуйтесь до спеціальної групи за інтересами Kubernetes Node Special Interest Group. Ми завжди раді новим учасникам та різноманітним поглядам на проблеми управління ресурсами.

Ingress NGINX: Заява комітетів з управління та реагування на загрози безпеки Kubernetes

Thu, 29 Jan 2026 00:00:00 +0000

У березні 2026 року Kubernetes припинить підтримку Ingress NGINX, важливої інфраструктури для приблизно половини хмарних середовищ. Припинення підтримки Ingress NGINX було оголошено на березень 2026 року після років публічних попереджень про те, що проєкт гостро потребує учасників та супровідників. Після припинення підтримки проєкту більше не буде випусків для виправлення помилок, патчів безпеки або будь-яких оновлень. Це не можна ігнорувати, відкидати або залишати на останню хвилину. Ми не можемо переоцінити серйозність ситуації та важливість негайного початку міграції на альтернативні рішення, такі як Gateway API або один із багатьох сторонніх контролерів Ingress.

Щоб було абсолютно зрозуміло: рішення залишитися з Ingress NGINX після припинення його підтримки робить вас і ваших користувачів вразливими до атак. Жодна з доступних альтернатив не є прямою заміною. Це вимагатиме часу на планування та розробку. Половина з вас буде зачеплена цією проблемою. У вас залишилося два місяці на підготовку.

Поточні розгортання продовжуватимуть працювати, тому, якщо ви не перевірите це самостійно, ви можете не знати, що вас це стосується, доки ви не станете жертвою атаки. У більшості випадків ви можете перевірити, чи використовуєте ви Ingress NGINX, запустивши kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx з правами адміністратора кластера.

Попри широку популярність і поширене використання компаніями різного розміру, а також неодноразові заклики про допомогу від розробників, проєкт Ingress NGINX так і не отримав необхідних йому учасників. Згідно з внутрішнім дослідженням Datadog, близько 50% хмарних середовищ наразі залежать від цього інструменту, проте протягом останніх кількох років його підтримували лише одна або дві особи, які працювали у вільний час. Без достатньої кількості персоналу для підтримки інструменту на рівні, який ми та наші користувачі вважаємо безпечним, відповідальним рішенням є поступова відмова від нього та переорієнтація зусиль на сучасні альтернативи, такі як Gateway API.

Це рішення було прийнято нелегко; незважаючи на незручності, які це спричинить, воно є необхідним для безпеки всіх користувачів та екосистеми в цілому. На жаль, гнучкість, з якою був розроблений Ingress NGINX, яка колись була благом, стала тягарем, який неможливо подолати. З накопиченим технічним боргом та фундаментальними проєктними рішеннями, що посилюють недоліки безпеки, продовжувати підтримувати інструмент, навіть якщо б ресурси зʼявилися, більше не є розумним і навіть можливим.

Ми робимо цю заяву спільно, щоб підкреслити масштаб цієї зміни та потенційний серйозний ризик для значної частини користувачів Kubernetes, якщо цю проблему ігнорувати. Необхідно негайно перевірити свої кластери. Якщо ви покладаєтеся на Ingress NGINX, вам слід почати планувати міграцію.

Дякуємо,

Керівний комітет Kubernetes

Комітет з реагування на загрози безпеки Kubernetes

Експерименти з Gateway API за допомогою kind

Wed, 28 Jan 2026 00:00:00 +0000

Цей документ проведе вас через налаштування локального експериментального середовища з Gateway API з використанням kind. Це середовище розроблено для навчання та тестування. Воно допомагає вам зрозуміти концепції Gateway API без складності промислового середовища.

Увага:

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

Огляд

У цьому посібнику ви:

Налаштуєте локальний кластер Kubernetes за допомогою kind (Kubernetes in Docker)
Розгорнете cloud-provider-kind, який надає як LoadBalancer Services, так і контролер Gateway API
Створите Gateway і HTTPRoute для маршрутизації трафіку до демо-застосунку
Протестуєте вашу конфігурацію Gateway API локально

Це середовище ідеально підходить для навчання, розробки та експериментування з концепціями Gateway API.

Передумови

Перед початком переконайтеся, що у вас встановлено наступне на локальному компʼютері:

Docker — Необхідний для запуску kind та cloud-provider-kind
kubectl — Інструмент командного рядка Kubernetes
kind — Kubernetes in Docker
curl — Необхідний для тестування маршрутів

Створення кластера kind

Створіть новий кластер kind, запустивши:

kind create cluster

Це створить одновузловий кластер Kubernetes, який працює в контейнері Docker.

Встановлення cloud-provider-kind

Далі вам потрібен cloud-provider-kind, який надає два ключові компоненти для цього середовища:

Контролер LoadBalancer, який призначає адреси сервісам типу LoadBalancer
Контролер Gateway API, який реалізує специфікацію Gateway API

Він також автоматично встановлює Custom Resource Definitions (CRDs) Gateway API у вашому кластері.

Запустіть cloud-provider-kind як контейнер Docker на тому ж хості, де ви створили кластер kind:

VERSION="$(basename $(curl -s -L -o /dev/null -w '%{url_effective}' https://github.com/kubernetes-sigs/cloud-provider-kind/releases/latest))"
docker run -d --name cloud-provider-kind --rm --network host -v /var/run/docker.sock:/var/run/docker.sock registry.k8s.io/cloud-provider-kind/cloud-controller-manager:${VERSION}

Примітка: На деяких системах вам може знадобитися підвищені права доступу до сокета Docker.

Перевірте, що cloud-provider-kind запущений:

docker ps --filter name=cloud-provider-kind

Ви повинні побачити контейнер у списку та в стані виконання. Ви також можете перевірити журнали:

docker logs cloud-provider-kind

Експериментування з Gateway API

Тепер, коли ваш кластер налаштований, ви можете почати експериментування з ресурсами Gateway API.

cloud-provider-kind автоматично надає GatewayClass під назвою cloud-provider-kind. Ви будете використовувати цей клас для створення вашого Gateway.

Варто зауважити, що хоча kind не є хмарним провайдером, проєкт названий cloud-provider-kind, оскільки він надає функції, які імітують хмарне середовище.

Розгортання Gateway

Наступний маніфест буде:

Створювати новий простір імен gateway-infra
Розгорнтати Gateway, який слухає на порту 80
Приймати HTTPRoutes з іменами хостів, які відповідають шаблону *.exampledomain.example
Дозволить маршрутам з будь-якого простору імен приєднуватися до Gateway. Примітка: У реальних кластерах використовуйте значення Same або Selector у полі allowedRoutes namespace selector, щоб обмежити приєднання.

Застосуйте наступний маніфест:

---
apiVersion: v1
kind: Namespace
metadata:
  name: gateway-infra
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: gateway
  namespace: gateway-infra
spec:
  gatewayClassName: cloud-provider-kind
  listeners:
  - name: default
    hostname: "*.exampledomain.example"
    port: 80
    protocol: HTTP
    allowedRoutes:
      namespaces:
        from: All

Потім перевірте, що ваш Gateway правильно запрограмований і має призначену адресу:

kubectl get gateway -n gateway-infra gateway

Очікуваний результат:

NAME      CLASS                 ADDRESS      PROGRAMMED   AGE
gateway   cloud-provider-kind   172.18.0.3   True         5m6s

Колона PROGRAMMED повинна показувати True, а поле ADDRESS повинно містити IP-адресу.

Розгортання демо-застосунку

Далі розгорніть простий echo-застосунок, який допоможе вам протестувати конфігурацію вашого Gateway. Цей застосунок:

Слухає на порту 3000
Повертає деталі запиту, включаючи шлях, заголовки та змінні середовища
Запускається у просторі імен demo

Застосуйте наступний маніфест:

apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: echo
  name: echo
  namespace: demo
spec:
  ports:
  - name: http
    port: 3000
    protocol: TCP
    targetPort: 3000
  selector:
    app.kubernetes.io/name: echo
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/name: echo
  name: echo
  namespace: demo
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: echo
  template:
    metadata:
      labels:
        app.kubernetes.io/name: echo
    spec:
      containers:
      - env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
        - name: NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        image: registry.k8s.io/gateway-api/echo-basic:v20251204-v1.4.1
        name: echo-basic

Створення HTTPRoute

Тепер створіть HTTPRoute для маршрутизації трафіку з вашого Gateway до echo-застосунку. Цей HTTPRoute буде:

Реагувати на запити для імені хоста some.exampledomain.example
Маршрутизувати трафік до echo-застосунку
Приєднуватися до Gateway у просторі імен gateway-infra

Застосуйте наступний маніфест:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: echo
  namespace: demo
spec:
  parentRefs:
  - name: gateway
    namespace: gateway-infra
  hostnames: ["some.exampledomain.example"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: echo
      port: 3000

Тестування вашого маршруту

Завершальний крок — перевірка вашого маршруту за допомогою curl. Ви зробите запит на IP-адресу Gateway з іменем хоста some.exampledomain.example. Наступна команда підходить тільки для POSIX shell і може потребувати налаштування для вашого середовища:

GW_ADDR=$(kubectl get gateway -n gateway-infra gateway -o jsonpath='{.status.addresses[0].value}')
curl --resolve some.exampledomain.example:80:${GW_ADDR} http://some.exampledomain.example

Ви повинні отримати JSON-відповідь подібну до цієї:

{
 "path": "/",
 "host": "some.exampledomain.example",
 "method": "GET",
 "proto": "HTTP/1.1",
 "headers": {
  "Accept": [
   "*/*"
  ],
  "User-Agent": [
   "curl/8.15.0"
  ]
 },
 "namespace": "demo",
 "ingress": "",
 "service": "",
 "pod": "echo-dc48d7cf8-vs2df"
}

Якщо ви бачите цю відповідь, вітаємо! Ваше середовище Gateway API працює правильно.

Усунення несправностей

Якщо щось працює не так, як очікується, ви можете усунути несправності, перевіривши стан ваших ресурсів.

Перевірка стану Gateway

Спочатку перевірте ресурс Gateway:

kubectl get gateway -n gateway-infra gateway -o yaml

Подивіться на розділ status на стани. Ваш Gateway повинен мати:

Accepted: True - Gateway був прийнятий контролером
Programmed: True - Gateway був успішно налаштований
.status.addresses заповнений IP-адресою

Перевірка стану HTTPRoute

Далі перевірте ваш HTTPRoute:

kubectl get httproute -n demo echo -o yaml

Перевірте розділ status.parents. Поширені проблеми включають:

ResolvedRefs встановлено False з причиною BackendNotFound; це означає, що сервіс бекенду не має або має неправильне імʼя
Accepted встановлено False; це означає, що маршрут не міг приєднатися до Gateway (перевірте дозволи простору імен або відповідність імені хосту)

Приклад помилки, коли бекенд не знайдено:

status:
  parents:
  - conditions:
    - lastTransitionTime: "2026-01-19T17:13:35Z"
      message: backend not found
      observedGeneration: 2
      reason: BackendNotFound
      status: "False"
      type: ResolvedRefs
    controllerName: kind.sigs.k8s.io/gateway-controller

Перевірка журналів контролера

Якщо стани ресурсів не розкривають проблему, перевірте журнали cloud-provider-kind:

docker logs -f cloud-provider-kind

Це покаже детальні журнали як з контролерів LoadBalancer, так і Gateway API.

Очищення

Коли ви закінчите з експериментами, ви можете очистити ресурси:

Видалення ресурсів Kubernetes

Видаліть простори імен (це видалить усі ресурси в них):

kubectl delete namespace gateway-infra
kubectl delete namespace demo

Зупинка cloud-provider-kind

Зупиніть та видаліть контейнер cloud-provider-kind:

docker stop cloud-provider-kind

Оскільки контейнер був запущений з прапорцем --rm, він буде автоматично видалений при зупинці.

Видалення кластера kind

Нарешті, видаліть кластер kind:

kind delete cluster

Наступні кроки

Тепер, коли ви поекспериментували з Gateway API локально, ви готові дослідити готові до промислової експлуатації реалізації:

Розгортання в промисловій експлуатації: Переглядайте реалізації Gateway API, щоб знайти контролер, який відповідає вашим вимогам до експлуатації
Дізнайтеся більше: Ознайомтесь з документацію Gateway API, щоб дізнатися про передові функції, такі як TLS, розподіл трафіку та маніпуляція заголовками
Розширена маршрутизація: Експериментуйте з маршрутизацією на основі шляху, узгодженням заголовків, дзеркальним відображенням запитів та іншими функціями, слідуючи посібникам користувача Gateway API

Фінальне попередження

Це середовище kind призначене лише для розробки та навчання. Завжди використовуйте реалізацію Gateway API промислового рівня для реальних робочих навантажень.

Cluster API v1.12: Впровадження оновлень на місці та ланцюгових оновлень

Tue, 27 Jan 2026 08:00:00 -0800

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

Подібно до того, як ви можете використовувати StatefulSets або Deployments в Kubernetes для управління групою Pods, в Cluster API ви можете використовувати KubeadmControlPlane для управління набором машин панелі упрвління або MachineDeployments для управління групою робочих вузлів.

Випуск Cluster API v1.12.0 розширює можливості Cluster API, зменшуючи складності у звичайних операціях життєвого циклу завдяки впровадженню оновлень на місці та ланцюгових оновлень.

Акцент на простоті та зручності використання

Cluster API завжди прагнув забезпечити простий і передбачуваний процес управління життєвим циклом кластерів Kubernetes.

З версією v1.12.0 проєкт Cluster API ще раз демонструє, що ця спільнота здатна запроваджувати велику кількість інновацій, одночасно мінімізуючи вплив на користувачів Cluster API.

Що це означає на практиці?

Користувачам просто потрібно змінити специфікацію [Cluster](https://cluster-api.sigs.k8s.io/user/concepts# cluster) або Machine spec (так само, як і в попередніх версіях Cluster API), і Cluster API автоматично запустить оновлення на місці або послідовні оновлення, коли це можливо і доцільно.

Оновлення на місці

Як і Kubernetes для Pods у Deployments, коли змінюється специфікація Machine, Cluster API також виконує розгортання, створюючи нову машину та видаляючи стару.

Цей підхід, навіяний принципом незмінної інфраструктури, має низку значних переваг:

Він простий для пояснення, передбачуваний, послідовний і легкий для розуміння користувачами та інженерами.
Він простий у реалізації, оскільки базується лише на двох основних операціях: створенні та видаленні.
Реалізація не залежить від конкретних параметрів машини, таких як ОС, механізм завантаження тощо.

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

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

Згодом Cluster API також запровадив кілька вдосконалень до незмінних розгортань, зокрема:

Підтримка поширення змін, що впливають тільки на ресурси Kubernetes, що дозволяє уникнути непотрібних розгортань
Спосіб позначення застарілих вузлів за допомогою PreferNoSchedule, що дозволяє зменшити кількість втрат Podʼів шляхом оптимізації перепланування Podʼів під час розгортань.
Підтримка стратегії «спочатку видалити, потім розгорнути», що спрощує розгортання незмінних версій на фізичних серверах/у середовищах з обмеженими ресурсами.

Нова функція оновлення на місці в Cluster API є наступним кроком на цьому шляху.

З випуском версії 1.12.0 Cluster API впроваджує підтримку розширень оновлення, що дозволяє користувачам вносити зміни в діючі машини на місці, без видалення та повторного створення машин.

Як KubeadmControlPlane, так і MachineDeployments підтримують оновлення на місці на основі нового розширення оновлення, а це означає, що межі можливостей Cluster API тепер значно змінилися.

Як працюють оновлення на місці?

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

Новина полягає в тому, що тепер Cluster API може вибирати між незмінними розгортаннями та розширеннями оновлень на місці для виконання необхідних змін.

Важливо, що це не незмінні розгортання проти оновлень на місці; Cluster API розглядає обидва варіанти як дійсні та вибирає найбільш відповідний механізм для даної зміни.

З точки зору розробників Cluster API, оновлення на місці найбільш корисні для внесення змін, які не вимагають спорожнення вузла або перезапуску подів; наприклад: зміна облікових даних користувача для машини. З іншого боку, коли робоче навантаження все одно буде порушено, просто виконайте розгортання.

Тим не менш, Cluster API залишається вірним своїй розширюваній природі, і кожен може створити власне розширення оновлення та вирішити, коли і як використовувати оновлення на місці, обмінявши деякі переваги незмінних розгортань.

Щоб глибше ознайомитися з цією функцією, обовʼязково відвідайте сесію Оновлення на місці з Cluster API: золота середина між незмінною та змінною інфраструктурою на KubeCon EU в Амстердамі!

Ланцюгові оновлення

ClusterClass та керовані топології в Cluster API спільно забезпечили потужну та ефективну структуру, яка слугує будівельним блоком для багатьох платформ, що пропонують Kubernetes-as-a-Service.

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

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

Найпростіший спосіб пояснити, як працюють ланцюгові оновлення, полягає в тому, що після того, як користувач запускає оновлення, змінюючи бажану версію для кластера, Cluster API обчислює план оновлення, а потім починає його виконувати. Замість того, щоб (наприклад) оновлювати кластер до v1.33.0, потім до v1.34.0, а потім до v1.35.0, перевіряючи прогрес на кожному кроці, ланцюгове оновлення дозволяє перейти безпосередньо до v1.35.0.

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

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

Також у цьому випадку розширюваність є основою цієї функції, і розширення виконання плану оновлення можуть бути використані для впливу на те, як обчислюється план оновлення; аналогічно, хуки життєвого циклу можуть використовуватися для автоматизації інших завдань, які необхідно виконати під час оновлення, наприклад, оновлення надбудови після завершення оновлення панелі управління.

На наш погляд, ланцюгові оновлення найбільш корисні для користувачів, яким важко встигати за мінорними релізами Kubernetes і які, наприклад, хочуть оновлюватися лише раз на рік, а потім оновлюватися на три версії (n-3 → n). Але майте на увазі: те, що тепер ви можете легко оновлюватися більш ніж на одну мінорну версію, не є приводом для того, щоб не оновлювати свій кластер регулярно!

Команда випуску

Я хотів би подякувати всім учасникам, адміністраторам та інженерам, які добровільно долучилися до команди випуску.

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

Висловлюємо подяку всій спільноті Cluster API за випуск версії 1.12.0 та всі чудові випуски, представлені у 2025 році! Якщо ви зацікавлені у співпраці, ознайомтеся з рекомендаціями щодо співпраці з Cluster API.

Що далі?

Якщо ви прочитаєте Маніфест Cluster API, то побачите, як в рамках субпроєкту Cluster API проголошується право залишатися незавершеним, визнаючи необхідність постійного розвитку, вдосконалення та адаптації до мінливих потреб користувачів Cluster API та ширшої екосистеми Cloud Native.

Оскільки Kubernetes продовжує розвиватися, супроєкт Cluster API буде просуватися разом з ним, зосереджуючись на безпечніших оновленнях, зменшенні перебоїв у роботі та зміцненні будівельних блоків для платформ, що управляють Kubernetes у великих масштабах.

Інновації залишаються в центрі уваги Cluster API, тож чекайте на насичений подіями 2026 рік!

Корисні посилання:

Headlamp у 2025 році: ключові моменти проєкту

Thu, 22 Jan 2026 10:00:00 +0800

Це повідомлення є підсумком публікації, яка спочатку була опублікована у блозі Headlamp.

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

Ми хотіли б поділитися кількома оновленнями та розповісти про те, як Headlamp розвивався протягом останнього року.

Оновлення

Приєднання до Kubernetes SIG UI

Цей рік став важливою віхою для проєкту: Headlamp тепер офіційно є частиною Kubernetes SIG UI. Цей крок ще більше наближає обговорення планів розвитку та дизайну до основної спільноти Kubernetes і підкріплює роль Headlamp як сучасного, розширюваного інтерфейсу для проєкту.

У рамках цього ми також ділимося інформацією про те, як зробити Kubernetes доступнішим для ширшої аудиторії, зокрема виступили в програмі Enlightening with Whitney Lee та виступ на KCD New York 2025.

Програма наставництва від Linux Foundation

Цього року ми були раді співпрацювати з кількома студентами в рамках програми наставництва від Linux Foundation, і наші підопічні вже залишили помітний слід у Headlamp:

Адвайте Годболе створив втулок KEDA, додавши в Headlamp інтерфейс для перегляду та управління ресурсами KEDA, такими як ScaledObjects і ScaledJobs.
Дхарія Маджмудар налаштував стек спостережності на основі OpenTelemetry для Headlamp, підключивши метрики, журнали та трасування, щоб спростити моніторинг та налагодження проєкту.
Айшварія Гатоле очолила аудит UX втулків Headlamp, виявляючи проблеми зі зручністю користування та пропонуючи поліпшення дизайну та персоналії для користувачів втулків.
Анірбан Сінга розробив втулок Karpenter, що надає Headlamp цілеспрямований огляд ресурсів та рішень Karpenter з автомасштабування.
Адтія Чаудхарі поліпшив підтримку Gateway API, завдяки чому ви можете бачити мережеві взаємозвʼязки на мапі ресурсів, а також поліпшив підтримку багатьох нових ресурсів Gateway API.
Фаахір Захід завершив роботу над способом легкого управління встановленням втулків за допомогою Headlamp, розгорнутого в кластерах.
Саурав Упадхʼяй працював над кешуванням в бекенді для викликів Kubernetes API, зменшивши навантаження на API-сервер і покращивши продуктивність Headlamp.

Нові зміни

Перегляд декількох кластерів

Управління декількома кластерами є складним завданням: команди часто переключаються між інструментами і втрачають контекст, намагаючись зрозуміти, що де працює. Headlamp вирішує цю проблему, надаючи єдиний перегляд для порівняння кластерів поруч. Це полегшує розуміння робочих навантажень у різних середовищах і скорочує час, витрачений на пошук ресурсів.

Перегляд багатокластерних робочих навантажень

Проєкти

Застосунки Kubernets часто охоплюють кілька просторів імен та типів ресурсів, що робить усунення несправностей схожим на складання пазла. Ми додали Проєкти, щоб надати вам орієнтований на застосунки перегляд, який групує повʼязані ресурси в декількох просторах імен і навіть кластерах. Це дозволяє зменшити розростання, швидше усувати несправності та співпрацювати, не переглядаючи YAML або списки для всього кластера.

Вигляд нової функції «Проєкти»

Зміни:

Нова функція «Проєкти» для групування просторів імен у проєкти, орієнтовані на застосунки або команди
Розширюваний вигляд деталей проєктів, який можна налаштувати за допомогою втулків із власними вкладками та діями

Повсякденна робота в Kubernetes часто означає перемикання між логами, терміналами, YAML та дашбордами в різних кластерах. Ми переробили навігацію Headlamp, щоб розглядати ці елементи як найважливіші «дії», які можна залишити відкритими та повернутися до них, а не як одноразові вікна, які зникають, щойно ви натискаєте в іншому місцц.

Вигляд нової панелі завдань

Зміни:

Нова панель завдань/модель активності дозволяє закріплювати журнали, сесії виконання та деталі як поточні активності
Огляд активності з дією «Закрити все» та інформацією про кластер
Вибір декількох елементів та глобальні фільтри в таблицях

Дякуємо Яну Янсену та Адітья Чаудхарі.

Пошук та мапа

Коли щось ламається у робочому середовищі, перші два питання зазвичай звучать так: «Де це?» і «З чим це пов'язано?». Ми оновили як пошук, так і відображення на карті, щоб ви могли набагато швидше перейти від загальних симптомів до потрібного набору об'єктів.

Вигляд нової функції розширеного пошуку

Зміни:

Розширений пошук, що підтримує розширені запити на основі виразів для обʼєктів Kubernetes
Покращений глобальний пошук, що розуміє мітки та кілька пошукових елементів і навіть може оновлювати ваш поточний простір імен на основі знайденого
Підтримка EndpointSlice у розділі «Мережа»
Розширений вигляд мапи, що тепер включає обʼєкти Custom Resources та Gateway API

Дякуємо Фабіану, Александру Норту та Віктору Марколіно зі Swisscom, а також Адітья Чаудхарі.

OIDC та автентифікація

Ми доклали чимало зусиль, щоб зробити налаштування OIDC більш зрозумілим і надійним, особливо для розгортання в кластері.

Перегляд інформації про користувача для кластерів OIDC

Зміни:

Інформація про користувача відображається у верхній панелі для користувачів, автентифікованих за допомогою OIDC
Підтримка PKCE для більш безпечних процесів автентифікації, а також зміцнене оновлення токенів
Документація щодо використання токена доступу за допомогою -oidc-use-access-token=true
Покращена підтримка публічних клієнтів OIDC, таких як AKS та EKS
Новий посібник із налаштування Headlamp на AKS з Azure Entra-ID за допомогою OAuth2Proxy

Дякуємо Девіду Добмейеру та Харшу Срівастава.

Каталог застосунків та Helm

Ми розширили можливості розгортання та пошуку застосунків за допомогою Headlamp, зокрема додавши підтримку репозиторіїв Helm.

Зміни:

Функціональніші чарти Helm з опціональною підтримкою TLS-термінації бекенду, PodDisruptionBudgets, налаштованими мітками подів тощо
Покращене форматування та додавання аргументу access token, якого бракувало в чартах Helm
Нова підтримка Helm у кластері з прапорцем --enable-helm та проксі-сервісом

Дякуємо Врушалі Шах та Муралі Аннамнені з Oracle, а також Пату Ріхекі, Джошуа Акерсу, Ростиславу Стржибрному, Ріку Л. та Віктору.

Продуктивність, доступність та UX

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

Вигляд розділу «Навчання» в документації

Зміни:

Істотні вдосконалення для настільних компʼютерів: завантаження застосунків стало на 60% швидшим, а перезавантаження в режимі розробки для учасників — значно швидшим
Численні вдосконалення таблиць і перегляду журналів: постійний порядок сортування, узгоджені дії з рядками, кнопки копіювання імен, кращі підказки та більш толерантні введення журналів
Вдосконалення доступності та локалізації, включаючи виправлення проблем з макетом, повʼязаних із масштабуванням, кращий контраст кольорів, покращену підтримку екранного зчитувача та розширене мовне покриття
Більший контроль над ресурсами, з показниками CPU/памʼяті під час роботи, більш детальною інформацією про поди та редагуванням секретів і полів CRD безпосередньо в тексті
Оновлена документація та досвід роботи з втулками, включаючи розділ «Навчання» та демонстрацію втулків
Більш повний інтерфейс NetworkPolicy та вдосконалення, повʼязані з мережею
Нічні збірки доступні для раннього тестування

Дякуємо Jaehan Byun та Jan Jansen.

Втулки та розширюваність

Тепер знайти втулки стало простіше — більше не потрібно переходити між Artifact Hub та різними репозиторіями GitHub. Перегляньте нашу спеціальну сторінку втулків, де ви знайдете добірку втулків, схвалених Headlamp, а також презентацію популярних втулків.

Вигляд демонстрації втулків

AI-асистент Headlamp

Управління Kubernetes часто означає запамʼятовування команд і маніпулювання інструментами. Новий AI Assistant від Headlamp змінює це, додаючи вбудований в UI інтерфейс природної мови. Тепер замість того, щоб вводити kubectl або порпатися в YAML, ви можете запитати: «Чи працює мій застосунок?», або «Покажи журнали для цього розгортання» і отримати відповіді в контексті, що прискорює усунення несправностей і полегшує адаптацію нових користувачів. Дізнайтеся більше про це тут.

Додавання нових втулків

Поряд з новим AI Assistant, ми розширюємо екосистему втулків Headlamp, щоб ви могли обʼєднати більше своїх робочих процесів в одному інтерфейсі користувача, завдяки інтеграції таких втулків, як Minikube, Karpenter та інших.

Основні моменти з останніх випусків втулків:

Втулок Minikube, що забезпечує локально збережений кластер Minikube з одним вузлом
Втулок Karpenter із підтримкою Azure Node Auto-Provisioning (NAP)
Втулок KEDA, про який ви можете дізнатися більше тут
Втулки, що підтримуються спільнотою, для Gatekeeper та KAITO

Дякуємо Врушалі Шах та Муралі Аннамнені з Oracle, а також Анірбану Сінзі, Адвайт Годболе, Сертач Озеркан, Ернест Вонг та Хлоя Лім.

Інші оновлення втулків

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

Вигляд втулка Backstage

Зміни:

Втулок Flux: оновлено для Flux v2.7, з підтримкою нових CRD, виправленнями навігації, для безперебійної роботи на останніх кластерах
Каталог застосунків: тепер підтримує репозиторії Helm на додачу до Artifact Hub, може працювати в кластері через /serviceproxy та показує як поточні, так і останні версії застосунків
Каталог втулків: покращено макет карток та доступність, а також оновлено залежність та тести Storybook
Втулок Backstage: оновлено залежність та збірку, детальніше тут

Розробка втулків

Ми зосередилися на тому, щоб зробити процес створення, тестування та постачання втулків Headlamp швидшим і зрозумілішим, спираючись на вдосконалену документацію та легші інструменти.

Вигляд посібника з розробки втулків

Зміни:

Нові та розширені посібники з архітектури втулків та розробки, включаючи інформацію про те, як публікувати та поширювати втулки
Додано документацію щодо підтримки i18n, щоб втулки можна було перекладати та локалізувати
Додано приклади втулків: ui-panels, resource-charts, custom-theme та projects
Покращено перевірку типів для API Headlamp, відновлено підтримку Storybook для тестування компонентів та зменшено кількість залежностей для пришвидшення встановлення та зменшення кількості оновлень
Задокументовано місця встановлення втулків, позначки інтерфейсу користувача в налаштуваннях втулків та мітки, що розрізняють втулки, які постачаються, встановлюються через інтерфейс користувача та в режимі розробки

Оновлення безпеки

Ми також працюємо над забезпеченням безпеки Headlamp — як шляхом посилення механізмів автентифікації, так і шляхом постійного відстеження вразливостей та оновлення інструментів.

Оновлення:

Ми регулярно оновлюємо залежні компоненти та усуваємо проблеми безпеки, слідкуючи за оновленнями безпеки.
Ми посилили стандартний контекст безпеки Helm chart і виправили регресію, яка порушувала роботу менеджера втулків.
Ми поліпшили безпеку OIDC за допомогою підтримки PKCE, що допомагає розблокувати більш безпечні та сумісні зі стандартами налаштування OIDC під час розгортання Headlamp у кластері.

Висновок

Дякуємо всім, хто зробив свій внесок у Headlamp цього року — чи то за допомогою pull-requests, втулків, чи просто розповівши про те, як ви використовуєте цей проєкт. Бачити, як різні команди впроваджують і розширюють проєкт, — це те, що значною мірою спонукає нас рухатися вперед. Якщо ваша організація використовує Headlamp, розгляньте можливість додати її до нашого списку користувачів.

Якщо ви ще не мали нагоди випробувати Headlamp, всі ці оновлення вже доступні. Ознайомтеся з останньою версією Headlamp, випробуйте нові режими перегляду, втулки та документацію, а також поділіться з нами своїми відгуками в Slack або GitHub — ваші відгуки допомагають нам визначати подальший розвиток Headlamp.

Оголошення про створення робочої групи Checkpoint/Restore Working Group

Wed, 21 Jan 2026 10:00:00 -0800

Спільнота навколо Kubernetes включає в себе ряд спеціальних груп за інтересами (SIG) та робочих груп (WG), які сприяють обговоренню важливих тем між зацікавленими учасниками. Сьогодні ми хотіли б оголосити про створення нової робочої групи Kubernetes Checkpoint Restore WG, яка зосередиться на інтеграції функціоналу Checkpoint/Restore в Kubernetes.

Мотивація та випадки використання

Робоча група обговорює кілька сценаріїв високого рівня:

Оптимізація використання ресурсів для інтерактивних робочих навантажень, таких як Jupyter notebook та чат-боти зі штучним інтелектом
Прискорення запуску застосунків з тривалим часом ініціалізації, включаючи Java-застосунки та служби LLM-інференції
Використання періодичних контрольних точок для забезпечення відмовостійкості довготривалих робочих навантажень, таких як розподілене навчання моделей
Забезпечення планування з урахуванням переривань з прозорою перевіркою/відновленням, що дозволяє витісняти Pod з нижчим пріоритетом, зберігаючи стан виконання застосунків
Спрощення міграції Podʼів між вузлами для балансування навантаження та обслуговування без переривання робочих навантажень.
Увімкнення перевірки для розслідування та аналізу інцидентів безпеки, таких як кібератаки, порушення безпеки даних та несанкціонований доступ.

У всіх цих сценаріях мета полягає в тому, щоб сприяти обговоренню ідей між спільнотою Kubernetes та екосистемою Checkpoint/Restore in Userspace (CRIU), яка постійно розширюється. Спільнота CRIU включає кілька проєктів, що підтримують ці випадки використання, зокрема:

CRIU — інструмент для створення контрольних точок та відновлення запущених застосунків і контейнерів
checkpointctl — інструмент для поглибленого аналізу контрольних точок контейнерів
criu-coordinator — інструмент для скоординованого створення контрольних точок/відновлення розподілених застосунків за допомогою CRIU
checkpoint-restore-operator — оператор Kubernetes для управління контрольними точками

Більше інформації про інтеграцію контрольних точок/відновлення з Kubernetes також доступно тут.

Після нашої презентації про прозорі контрольні точки на KubeCon EU 2025, ми раді запросити вас до участі в нашій панельній дискусії та сесії AI + ML на KubeCon + CloudNativeCon Europe 2026.

Звʼяжіться з нами

Якщо ви зацікавлені у співпраці з Kubernetes або CRIU, є кілька способів взяти участь:

Приєднуйтесь до наших зустрічей щодругого четверга о 17:00 UTC за посиланням Zoom у наших нотатках про зустрічі; записи наших попередніх зустрічей доступні тут.
Поспілкуйтеся з нами на Kubernetes Slack: #wg-checkpoint-restore
Надішліть нам електронного листа на адресу розсилки wg-checkpoint-restore

Уніфікований доступ до сервера API за допомогою clientcmd

Mon, 19 Jan 2026 10:00:00 -0800

Якщо ви коли-небудь хотіли створювати консольного клієнта для API Kubernetes, особливо якщо ви розглядали можливість використання вашого клієнта як втулка kubectl, ви, можливо, замислювалися над тим, як зробити вашого клієнта звичним для користувачів kubectl. Швидкий погляд на вихідні дані kubectl options може вас збентежити: «Невже я повинен реалізувати всі ці опції?»

Не бійтеся, інші вже зробили за вас велику частину роботи. Насправді проєкт Kubernetes надає дві бібліотеки, які допоможуть вам обробляти аргументи командного рядка в стилі kubectl у програмах Go: clientcmd та cli-runtime (яка використовує clientcmd). У цій статті ми покажемо, як використовувати першу з них.

Загальна філософія

Як і слід було очікувати, оскільки це частина client-go, кінцевою метою clientcmd є надання екземпляра restclient.Config, який може надсилати запити до сервера API.

Він дотримується семантики kubectl:

стандартні значення беруться з ~/.kube або еквівалентного файлу;
файли можна вказати за допомогою змінної середовища KUBECONFIG;
усі вищезазначені налаштування можна додатково замінити за допомогою аргументів командного рядка.

Він не встановлює аргумент командного рядка --kubeconfig, що може знадобитися для узгодження з kubectl; як це зробити, ви дізнаєтеся в розділі «Привʼязування прапорців».

Доступні функції

clientcmd дозволяє програмам обробляти

вибір kubeconfig (за допомогою KUBECONFIG);
вибір контексту;
вибір простору імен;
сертифікати клієнта та приватні ключі;
імітацію користувача;
підтримку базової автентифікації HTTP (імʼя користувача/пароль).

Обʼєднання конфігурацій

У різних сценаріях clientcmd підтримує обʼєднання параметрів конфігурацій: KUBECONFIG може вказувати декілька файлів, вміст яких обʼєднується. Це може викликати плутанину, оскільки параметри обʼєднуються в різних напрямках залежно від того, як вони реалізовані. Якщо параметр визначений у мапі, перше визначення має пріоритет, а наступні визначення ігноруються. Якщо параметр не визначений у мапі, останнє визначення має пріоритет.

Коли налаштування отримуються за допомогою KUBECONFIG, відсутні файли призводять лише до попереджень. Якщо користувач явно вказує шлях (у стилі --kubeconfig), повинен бути відповідний файл.

Якщо KUBECONFIG не визначено, замість нього використовується стандартний файл конфігурації ~/.kube/config, якщо він є.

Загальний процес

Загальна схема використання стисло викладена в документації до пакунка clientcmd:

loadingRules := clientcmd.NewDefaultClientConfigLoadingRules()
// якщо ви хочете змінити правила завантаження (які файли в якому порядку), ви можете зробити це тут

configOverrides := &clientcmd.ConfigOverrides{}
// якщо ви хочете змінити значення перевизначення або привʼязати їх до прапорців, є методи, які допоможуть вам

kubeConfig := clientcmd.NewNonInteractiveDeferredLoadingClientConfig(loadingRules, configOverrides)
config, err := kubeConfig.ClientConfig()
if err != nil {
	//Щось робимо
}
client, err := metav1.New(config)
// ...

У контексті цієї статті є шість кроків:

Налаштування правил завантаження

clientcmd.NewDefaultClientConfigLoadingRules() створює правила завантаження, які будуть використовувати або вміст змінної середовища KUBECONFIG, або імʼя стандартного файлу конфігурації (~/.kube/config). Крім того, якщо використовується стандартний файл конфігурації, він може перенести налаштування з (дуже) старого стандартного файлу конфігурації (~/.kube/.kubeconfig).

Ви можете створити власні ClientConfigLoadingRules, але в більшості випадків стандартні налаштування підходять.

Налаштування перевизначення

clientcmd.ConfigOverrides — це структура, що зберігає перевизначення, які будуть застосовані до налаштувань, завантажених із конфігурації, отриманої за допомогою правил завантаження. У контексті цієї статті її основною метою є зберігання значень, отриманих з аргументів командного рядка. Вони обробляються за допомогою бібліотеки pflag, яка є повноцінною заміною пакунка Go flag і додає підтримку аргументів з подвійним дефісом і довгими іменами.

У більшості випадків в перевизначеннях нічого не потрібно встановлювати; я лише привʼяжу їх до прапорців.

Створення набору прапорців

У цьому контексті прапорець є уособленням аргументу командного рядка, що вказує його повну назву (наприклад, --namespace), його скорочену назву, якщо така є (наприклад, -n), його стандартне значення та опис, що показується в інформації про використання. Прапорці зберігаються в екземплярах структури FlagInfo.

Доступні три набори прапорців, що представляють такі аргументи командного рядка:

аргументи автентифікації (сертифікати, токени, імітації іншого користувача, імʼя користувача/пароль);
аргументи кластера (сервер API, центр сертифікації, конфігурація TLS, проксі, стиснення)
аргументи контексту (ім'я кластера, імʼя користувача kubeconfig, простір імен)

Рекомендований вибір включає всі три з аргументом вибору іменованого контексту та аргументом часу очікування.

Всі вони доступні за допомогою функцій Recommended…Flags. Функції приймають префікс, який додається до всіх довгих імен аргументів.

Отже, виклик clientcmd.RecommendedConfigOverrideFlags(«») призводить до появи аргументів командного рядка, таких як --context, --namespace тощо. Аргументу --timeout присвоюється стандартне значення 0, а аргумент --namespace має відповідний короткий варіант -n. Додавання префікса, наприклад "from-", призводить до появи аргументів командного рядка, таких як --from-context, --from-namespace тощо. Це може здатися не особливо корисним для команд, що стосуються одного сервера API, але вони стають у пригоді, коли залучено кілька серверів API, наприклад у сценаріях із кількома кластерами.

Тут є потенційна проблема: префікси не змінюють коротке імʼя, тому --namespace потребує певної обережності, якщо використовується кілька префіксів: лише один із префіксів може бути повʼязаний із коротким імʼям -n. Вам доведеться очистити короткі імена, повʼязані з іншими префіксами --namespace, або, можливо, всі префікси, якщо немає логічного звʼязку з -n. Короткі імена можна очистити таким чином:

kflags := clientcmd.RecommendedConfigOverrideFlags(prefix)
kflags.ContextOverrideFlags.Namespace.ShortName = ""

Аналогічним чином прапорці можна повністю вимкнути, очистивши їх довге імʼя:

kflags.ContextOverrideFlags.Namespace.LongName = ""

Привʼязування прапорів

Після визначення набору прапорців його можна використовувати для привʼязки аргументів командного рядка до перевизначення за допомогою clientcmd.BindOverrideFlags. Для цього потрібен pflag FlagSet, а не пакунок flag з Go.

Якщо ви також хочете привʼязати --kubeconfig, зробіть це зараз, привʼязавши ExplicitPath у правилах завантаження:

flags.StringVarP(&loadingRules.ExplicitPath, "kubeconfig", "", "", "absolute path(s) to the kubeconfig file(s)")

Створення обʼєднаної конфігурації

Для створення обʼєднаної конфігурації доступні дві функції:

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

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

Отримання клієнта API

Обʼєднана конфігурація повертається як екземпляр ClientConfig. API-клієнт можна отримати з нього, викликавши метод ClientConfig().

Якщо конфігурація не вказана (KUBECONFIG порожній або вказує на відсутні файли, ~/.kube/config не існує, а конфігурація не вказана за допомогою аргументів командного рядка), стандартна настройка поверне незрозумілу помилку, що посилається на KUBERNETES_MASTER. Це застаріла поведінка; було зроблено кілька спроб позбутися її, але вона збереглася для аргументів командного рядка --local та --dry-run у --kubectl. Ви повинні перевіряти наявність помилок «порожньої конфігурації», викликаючи clientcmd.IsEmptyConfig(), і надавати чіткіше повідомлення про помилку.

Метод Namespace() також корисний: він повертає простір імен, який слід використовувати. Він також вказує, чи був простір імен перезаписаний користувачем (за допомогою --namespace).

Повний приклад

Ось повний приклад.

package main

import (
	"context"
	"fmt"
	"os"

	"github.com/spf13/pflag"
	v1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"k8s.io/client-go/kubernetes"
	"k8s.io/client-go/tools/clientcmd"
)

func main() {
	// Завантаження правил, без налаштувань
	loadingRules := clientcmd.NewDefaultClientConfigLoadingRules()

	// Перезапис і налаштування прапорця (аргумент командного рядка)
	configOverrides := &clientcmd.ConfigOverrides{}
	flags := pflag.NewFlagSet("clientcmddemo", pflag.ExitOnError)
	clientcmd.BindOverrideFlags(configOverrides, flags,
		clientcmd.RecommendedConfigOverrideFlags(""))
	flags.StringVarP(&loadingRules.ExplicitPath, "kubeconfig", "", "", "absolute path(s) to the kubeconfig file(s)")
	flags.Parse(os.Args)

	// Створення клієнта
	kubeConfig := clientcmd.NewNonInteractiveDeferredLoadingClientConfig(loadingRules, configOverrides)
	config, err := kubeConfig.ClientConfig()
	if err != nil {
		if clientcmd.IsEmptyConfig(err) {
			panic("Please provide a configuration pointing to the Kubernetes API server")
		}
		panic(err)
	}
	client, err := kubernetes.NewForConfig(config)
	if err != nil {
		panic(err)
	}

	// Як дізнатися, який простір імен використовувати
	namespace, overridden, err := kubeConfig.Namespace()
	if err != nil {
		panic(err)
	}
	fmt.Printf("Chosen namespace: %s; overridden: %t\n", namespace, overridden)

	// Використаємо клієнта
	nodeList, err := client.CoreV1().Nodes().List(context.TODO(), v1.ListOptions{})
	if err != nil {
		panic(err)
	}
	for _, node := range nodeList.Items {
		fmt.Println(node.Name)
	}
}

Приємного програмування та дякуємо за ваш інтерес до впровадження інструментів зі звичними моделями використання!

Kubernetes v1.35: До kuberc додано обмеження щодо виконуваних файлів, які викликаються kubeconfigs через exec plugin allowList

Fri, 09 Jan 2026 10:30:00 -0800

Чи знали ви, що kubectl може запускати довільні виконувані файли, включаючи скрипти оболонки, з повними правами користувача, який їх викликає, і навіть без вашого відома? Кожного разу, коли ви завантажуєте або автоматично генеруєте kubeconfig, поле users[n].exec.command може вказати виконуваний файл для отримання облікових даних від вашого імені. Не зрозумійте мене неправильно, це неймовірна функція, яка дозволяє вам пройти автентифікацію в кластері за допомогою зовнішніх постачальників ідентифікації. Проте, ви, мабуть, бачите проблему: чи знаєте ви точно, які виконувані файли ваш kubeconfig запускає у вашій системі? Чи довіряєте ви конвеєру, який згенерував ваш kubeconfig? Якщо на код, що генерує kubeconfig, було здійснено атаку на ланцюжок постачання, або якщо конвеєр генерації було скомпрометовано, зловмисник може робити неприємні речі з вашою машиною, змушуючи ваш kubeconfig виконувати довільний код.

Щоб надати користувачам більше контролю над тим, що виконується в їхній системі, SIG-Auth та SIG-CLI додали політику втулків для облікових даних та список дозволених елементів як бета-функцію до Kubernetes 1.35. Це доступно для всіх клієнтів, які використовують бібліотеку client-go, шляхом заповнення структури ExecProvider.PluginPolicy у конфігурації REST. Щоб розширити вплив цієї зміни, Kubernetes v1.35 також дозволяє керувати цим без написання жодної лінії програмного коду. Ви можете налаштувати kubectl для застосування політики та списку дозволеного, додавши два поля до файлу конфігурації kuberc: credentialPluginPolicy та credentialPluginAllowlist. Додавання одного або обох цих полів обмежує втулки облікових даних, які kubectl може виконувати.

Як це працює

Повний опис цієї функції доступний в нашій офіційній документації до kuberc, але в цьому блозі ми надамо короткий огляд нових налаштувань безпеки. Нові функції знаходяться в стадії бета-тестування і доступні без використання будь-яких функціональних обмежень.

Наступний приклад є найпростішим: просто не вказуйте нові поля.

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference

Це дозволить kubectl працювати як і раніше, а всі втулки будуть дозволені.

Наступний приклад функціонально ідентичний, але він є чіткішим і тому кращим, якщо це саме те, що вам потрібно:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: AllowAll

Якщо ви не знаєте, чи ви використовуєте exec втулки для облікових даних, спробуйте встановити політику на DenyAll:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: DenyAll

Якщо ви використовуєте втулки для введення облікових даних, ви швидко зʼясуєте, що намагається виконати kubectl. Ви отримаєте помилку, подібну до наведеної нижче.

Неможливо підключитися до сервера: отримання облікових даних: втулок «cloudco-login» не дозволений: політика встановлена на «DenyAll»

Якщо вам не вистачає інформації для усунення проблеми, збільште детальність логування під час виконання наступної команди. Наприклад:

# збільшити або зменшити детальність, якщо проблема все ще залишається незрозумілою
kubectl get pods --verbosity 5

Вибіркові дозволи для втулків

Що робити, якщо для щоденної роботи вам потрібен втулок cloudco-login? Саме для цього існує третій варіант політики — Allowlist. Щоб дозволити використання певного втулка, встановіть політику та додайте credentialPluginAllowlist:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
  - name: /usr/local/bin/cloudco-login
  - name: get-identity

Ви помітите, що в allowlist є два записи. Один з них вказаний повним шляхом, а інший, get-identity, є лише базовим іменем. Коли ви вказуєте лише базове імʼя, повний шлях буде шукатися за допомогою exec.LookPath, який не розширює globbing і не обробляє символи-замінники. Globbing наразі не підтримується. Обидві форми (базова назва та повний шлях) є прийнятними, але повний шлях є кращим, оскільки він ще більше звужує діапазон дозволених бінарних файлів.

Майбутні вдосконалення

Наразі запис у списку дозволеного (allowlist) має лише одне поле, name. У майбутньому ми (Kubernetes SIG CLI) хочемо додати інші вимоги. Однією з корисних ідей є перевірка контрольної суми, за допомогою якої, наприклад, бінарний файл можна буде запустити, тільки якщо він має суму sha256 b9a3fad00d848ff31960c44ebb5f8b92032dc085020f857c98e32a5d5900ff9c і знаходиться за адресою /usr/bin/cloudco-login.

Інша можливість — дозволити лише бінарні файли, підписані одним із довірених ключів підпису.

Приєднуйтесь

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

#sig-cli,
#sig-auth.

Kubernetes v1.35: Змінювана спорідненість вузлів PersistentVolume (альфа)

Thu, 08 Jan 2026 10:30:00 -0800

API спорідненості вузлів PersistentVolume зʼявився ще в Kubernetes v1.10. Він широко використовується для позначення того, що томи можуть бути не однаково доступними для всіх вузлів у кластері. Раніше це поле було незмінним, а тепер воно стало змінюваним у Kubernets v1.35 (альфа). Ця зміна відкриває можливості для більш гнучкого управління томами в режимі онлайн.

Для чого робити спорідненість вузлів змінюваною?

Це викликає очевидне запитання: чому зараз зробити спорідненість вузлів змінюваною? Хоча робочі навантаження без збереження стану, такі як Deployments, можна вільно змінювати, і зміни будуть автоматично впроваджуватися шляхом повторного створення кожного Podʼа, PersistentVolumes (PV) мають стан і їх не можна легко створити заново без втрати даних.

Однак постачальники послуг зберігання даних розвиваються, а вимоги до зберігання змінюються. Зокрема, зараз багато постачальників пропонують диски регіонального рівня. Деякі з них навіть підтримують міграцію в режимі реального часу з дискових зон на диски регіонального рівня без переривання робочих навантажень. Ця зміна може бути реалізована за допомогою API VolumeAttributesClass, який нещодавно перейшов у статус GA в версії 1.34. Однак навіть якщо том переміщено до регіонального сховища, Kubernetes все одно не дозволяє планувати Podʼи до інших зон через спорідненість вузлів, записану в обʼєкті PV. У цьому випадку можна змінити спорідненість вузлів PV з:

spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/zone
          operator: In
          values:
          - us-east1-b

на:

spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.kubernetes.io/region
          operator: In
          values:
          - us-east1

Іншим прикладом є те, що постачальники іноді пропонують диски нового покоління. Нові диски не завжди можна додати до старих вузлів у кластері. Ця доступність також може бути представлена через спорідненість вузлів PV і гарантує, що Podʼи можна запланувати на правильні вузли. Але коли диск оновлюється, нові Podʼи, що використовують цей диск, все одно можуть бути заплановані на старі вузли. Щоб цього уникнути, можна змінити спорідненість вузлів PV з:

spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: provider.com/disktype.gen1
          operator: In
          values:
          - available

на:

spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: provider.com/disktype.gen2
          operator: In
          values:
          - available

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

Спробуйте

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

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

Наразі ця функція перебуває в стадії альфа-тестування. Вона є стандартно вимкненою і може бути предметом змін. Щоб її випробувати, увімкніть можливість MutablePVNodeAffinity в APIServer, після чого ви зможете редагувати поле PV spec.nodeAffinity. Зазвичай PV можуть редагувати лише адміністратори, тому переконайтеся, що ви маєте відповідні дозволи RBAC.

Гонитва між оновленням і плануванням

Існує лише кілька факторів поза межами Podʼа, які можуть вплинути на рішення щодо планування, і спорідненість вузлів PV є одним з них. Можна дозволити більшій кількості вузлів отримати доступ до тому, послабивши спорідненість вузлів, але при спробі посилити спорідненість вузлів виникає стан конкуренції: незрозуміло, як планувальник побачить змінений PV у своєму кеші, тому існує невеликий проміжок часу, коли планувальник може розмістити Pod на старому вузлі, який більше не має доступу до тому. У цьому випадку Pod застрягне в стані ContainerCreating.

Одним зі способів усунення цієї проблеми, який зараз обговорюється, є відмова kubelet у запуску Podʼів, якщо порушується спорідненість вузлів PersistentVolume. Ця функція ще не реалізована. Тому, якщо ви пробуєте це зараз, стежте за наступними Podʼами, які використовують оновлений PV, і переконайтеся, що вони заплановані на вузли, які мають доступ до тому. Якщо ви оновлюєте PV і відразу запускаєте нові Podʼи в скрипті, це може не працювати як передбачалося.

Майбутня інтеграція з CSI (Container Storage Interface)

Наразі адміністратор кластера може змінювати як спорідненість вузлів PV, так і базовий том у постачальнику сховища. Однак ручні операції є помилковими та трудомісткими. Бажано з часом інтегрувати це з VolumeAttributesClass, щоб користувач без привілеїв міг змінювати свій PersistentVolumeClaim (PVC) для запуску оновлень на стороні сховища, а спорідненість вузлів PV оновлювалася автоматично в разі потреби без втручання адміністратора кластера.

Ми будемо раді отримати відгуки від користувачів та розробників драйверів сховищ

Як зазначалося раніше, це лише перший крок.

Якщо ви є користувачем Kubernetes, ми хотіли б дізнатися, як ви використовуєте (або будете використовувати) спорідненість вузлів PV. Чи є для вас корисним оновлення її в режимі онлайн?

Якщо ви розробник драйверів CSI, чи готові ви реалізувати цю функцію? Як би ви хотіли, щоб виглядав API?

Надішліть свої відгуки у:

Каналі Slack #sig-storage.
Списку розсилки kubernetes-sig-storage.
В тікеті KEP Mutable PersistentVolume Node Affinity.

З будь-якими запитаннями або конкретними питаннями, повʼязаними з цією функцією, звертайтеся до спільноти SIG Storage.

Kubernetes v1.35: Кращий спосіб передачі токенів службових облікових записів до драйверів CSI

Wed, 07 Jan 2026 10:30:00 -0800

Якщо ви підтримуєте драйвер CSI, який використовує токени службових облікових записів, Kubernetes v1.35 приносить удосконалення, про яке вам варто знати. З моменту введення функції TokenRequests, токени службових облікових записів, запитувані драйверами CSI, передавалися їм через поле volume_context. Хоча це працювало, це не ідеальне місце для конфіденційної інформації, і ми бачили випадки, коли токени випадково реєструвалися в драйверах CSI.

Kubernetes v1.35 вводить рішення бета-версії для вирішення цієї проблеми: Опція драйвера CSI для токенів службових облікових записів через поле Secrets. Це дозволяє драйверам CSI отримувати токени службових облікових записів через поле secrets у NodePublishVolumeRequest, яке є відповідним місцем для конфіденційних даних у специфікації CSI.

Розуміння поточного підходу

Коли драйвери CSI використовують функцію TokenRequests, вони можуть запитувати токени службових облікових записів для ідентифікації робочого навантаження, налаштовуючи поле TokenRequests у специфікації CSIDriver. Ці токени передаються драйверам як частина мапи атрибутів тому, використовуючи ключ csi.storage.k8s.io/serviceAccount.tokens.

Поле volume_context працює, але воно не призначене для конфіденційних даних. Через це виникають кілька викликів:

По-перше, інструмент protosanitizer, який використовують драйвери CSI, не розглядає контекст тому як конфіденційний, тому токени службових облікових записів можуть потрапити до журналів, коли реєструються gRPC-запити. Це сталося з CVE-2023-2878 у Secrets Store CSI Driver та CVE-2024-3744 у Azure File CSI Driver.

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

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

Як працює механізм увімкнення

Kubernetes v1.35 вводить механізм увімкнення, який дозволяє драйверам CSI вибирати, як вони отримують токени службових облікових записів. Таким чином, поточні драйвери продовжують працювати як і раніше, а інші драйвери можуть перейти до більш відповідного поля secrets, коли будуть готові.

Драйвери CSI можуть встановити нове поле у своїй специфікації CSIDriver:

#
# УВАГА: це приклад конфігурації.
#          Не використовуйте це для власного кластера!
#
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example-csi-driver
spec:
  # ... наявні поля ...
  tokenRequests:
  - audience: "example.com"
    expirationSeconds: 3600
  # Нове поле для опції доставки через secrets
  serviceAccountTokenInSecrets: true  # стандартно false

Поведінка залежить від поля serviceAccountTokenInSecrets:

Коли встановлено false (стандартно), токени розміщуються у VolumeContext з ключем csi.storage.k8s.io/serviceAccount.tokens, як і сьогодні. Коли встановлено true, токени розміщуються лише у полі Secrets з тим самим ключем.

Про бета-реліз

Функціональна можливість CSIServiceAccountTokenSecrets стандартно увімкнена як для kubelet, так і для kube-apiserver. Оскільки поле serviceAccountTokenInSecrets стандартно має значення false, увімкнення функціональної можливості не змінює жодної поточної поведінки. Усі драйвери продовжують отримувати токени через контекст тому, якщо вони явно не оберуться. Це пояснює, чому ми почувалися комфортно, починаючи з бета-версії, а не альфа.

Посібник для авторів драйверів CSI

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

Додавання резервної логіки

Спочатку оновіть код вашого драйвера, щоб перевіряти обидва місця на наявність токенів. Це робить ваш драйвер сумісним з обома підходами, старим і новим:

const serviceAccountTokenKey = "csi.storage.k8s.io/serviceAccount.tokens"

func getServiceAccountTokens(req *csi.NodePublishVolumeRequest) (string, error) {
    // Перевірити поле secrets спочатку (нова поведінка, коли драйвер обирається)
    if tokens, ok := req.Secrets[serviceAccountTokenKey]; ok {
        return tokens, nil
    }

    // Резерв до контексту тому (поточна поведінка)
    if tokens, ok := req.VolumeContext[serviceAccountTokenKey]; ok {
        return tokens, nil
    }

    return "", fmt.Errorf("service account tokens not found")
}

Ця резервна логіка є зворотньо сумісною та безпечною для випуску в будь-якій версії драйвера, навіть до оновлення кластерів до v1.35.

Послідовність розгортання

Автори драйверів CSI повинні дотримуватися певної послідовності при прийнятті цієї функції, щоб уникнути порушення наявних томів.

Підготовка драйвера (може відбутися будь-коли)

Ви можете почати підготовку вашого драйвера прямо зараз, додавши резервну логіку, яка перевіряє як поле secrets, так і контекст тому на наявність токенів. Ця зміна коду є зворотньо сумісною та безпечною для випуску в будь-якій версії драйвера, навіть до оновлення кластерів до v1.35. Ми заохочуємо вас додати цю логіку раніше, випускати релізи та навіть робити зворотні портування до гілок обслуговування, де це можливо.

Оновлення кластера та увімкнення функції

Після того, як ваш драйвер має резервну логіку, ось безпечний порядок розгортання для увімкнення функції в кластері:

Завершити оновлення kube-apiserver до 1.35 або пізнішої версії
Завершити оновлення kubelet до 1.35 або пізнішої версії на всіх вузлах
Переконатися, що версія драйвера CSI з резервною логікою розгорнута (якщо не зроблено в фазі підготовки)
Повністю завершити розгортання DaemonSet драйвера CSI на всіх вузлах
Оновити ваш маніфест CSIDriver, щоб встановити serviceAccountTokenInSecrets: true

Важливі обмеження

Найважливіше, що потрібно памʼятати, — це час. Якщо ваш DaemonSet драйвера CSI та обʼєкт CSIDriver знаходяться в одному маніфесті або чарті Helm, вам потрібно два окремі оновлення. Спочатку розгорніть нову версію драйвера з резервною логікою, зачекайте завершення розгортання DaemonSet, потім оновіть специфікацію CSIDriver, щоб встановити serviceAccountTokenInSecrets: true.

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

Чому це важливо

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

Це усуває ризик випадкового реєстрації токенів службових облікових записів як частини контексту тому в gRPC-запитах
Вона використовує призначене поле специфікації CSI для конфіденційних даних, що є правильним
Інструмент protosanitizer автоматично правильно обробляє поле secrets, тому вам не потрібні специфічні для драйвера обхідні шляхи
Це опціонально, тому ви можете мігрувати у власному темпі без порушення наявних розгортань

Заклик до дії

Ми (Kubernetes SIG Storage) заохочуємо авторів драйверів CSI прийняти цю функцію та надати відгуки про досвід міграції. Якщо у вас є думки щодо дизайну API або виникають будь-які проблеми під час прийняття, будь ласка, зверніться до нас у каналі #csi на Kubernetes Slack (для запрошення відвідайте https://slack.k8s.io/).

Ви можете стежити за KEP-5538 щоб відстежувати прогрес у наступних релізах Kubernetes.

Kubernetes v1.35: Розширені оператори толерантності для підтримки числових порівнянь (Alpha)

Mon, 05 Jan 2026 10:30:00 -0800

Багато робочих кластерів Kubernetes поєднують вузли на вимогу (вищий рівень SLA) та спот-вузли/вузли з правом витіснення (нижчий рівень SLA) для оптимізації витрат при збереженні надійності критичних робочих навантажень. Команди платформи потребують безпечного стандартного варіанту, який утримує більшість робочих навантажень подалі від ризикованих потужностей, одночасно дозволяючи певним робочим навантаженням підключатися з явними пороговими значеннями, такими як «Я можу толерувати вузли з імовірністю відмови до 5%».

Сьогодні Kubernetes taints і tolerations можуть відповідати точним значенням або перевіряти наявність, але вони не можуть порівнювати числові пороги. Вам потрібно буде створити дискретні категорії taint, використовувати зовнішні контролери допуску або приймати рішення про розміщення, що не є оптимальними.

У Kubernetes v1.35 ми впроваджуємо розширені оператори толерантності як альфа-функцію. Це вдосконалення додає оператори Gt (більше ніж) і Lt (менше ніж) до spec.tolerations, що дозволяє приймати рішення про планування на основі порогових значень, які відкривають нові можливості для розміщення на основі SLA, оптимізації витрат і розподілу робочих навантажень з урахуванням продуктивності.

Розвиток толерантностей

Історично Kubernetes підтримував два основні оператора толерантності:

Equal: толерантність відповідає позначці taint, якщо ключ і значення є абсолютно однаковими
Exists: толерантність відповідає позначці taint, якщо ключ присутній, незалежно від значення

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

Розглянемо такі реальні ситуації:

Вимоги SLA: планувати робочі навантаження з високою доступністю тільки на вузлах із ймовірністю відмови нижче певного порогу
Оптимізація витрат: Дозвольте виконувати чутливі до витрат пакетні завдання на дешевших вузлах, які перевищують певну вартість за годину
Гарантії продуктивності: Забезпечте, щоб чутливі до затримок застосунки виконувалися тільки на вузлах з дисковим IOPS або пропускною здатністю мережі вище мінімальних порогів

Без операторів числового порівняння оператори кластерів мусили вдаватися до обхідних рішень, таких як створення декількох дискретних значень taint або використання зовнішніх контролерів допуску, жоден з яких не масштабується добре і не забезпечує гнучкості, необхідної для динамічного планування на основі порогових значень.

Для чого розширювати толерантності замість використання NodeAffinity?

Ви можете запитати: NodeAffinity вже підтримує числові оператори порівняння, тож навіщо розширювати толерантності? Хоча NodeAffinity є потужним інструментом для вираження налаштувань подів, taints і tolerations надають важливі операційні переваги:

** Орієнтованість на політику**: NodeAffinity працює для кожного окремого пода, вимагаючи, щоб кожне робоче навантаження явно відмовлялося від ризикованих вузлів. Taints інвертують контроль — вузли заявляють свій рівень ризику, і тільки поди з відповідними tolerations можуть там розміщуватися. Це забезпечує більш безпечні стандартні налаштування; більшість подів тримаються подалі від spot/preemptible вузлів, якщо вони явно не вибирають їх.
Семантика виселення: NodeAffinity не має можливості виселення. Taints підтримують ефект NoExecute з tolerationSeconds, що дозволяє операторам виводити та виселяти поди, коли SLA вузла погіршується або спотові інстанції отримують повідомлення про припинення.
Ергономіка експлуатації: централізована політика на стороні вузла узгоджується з іншими безпечними taints, такими як навантаження на диск і навантаження на памʼять, що робить управління кластером більш інтуїтивним.

Це вдосконалення зберігає добре зрозумілу модель безпеки позначок і толерантності, одночасно забезпечуючи розміщення на основі порогових значень для планування з урахуванням SLA.

Представляємо оператори Gt та Lt

Kubernetes v1.35 представляє два нових оператори для толерантності:

Gt (більше ніж): толерантність застосовується, якщо числове значення taint більше за значення толерантності
Lt (менше ніж): толерантність застосовується, якщо числове значення taint менше за значення толерантності

Коли под толерує taint з Lt, це означає: «Я можу толерувати вузли, де цей показник менший за мій поріг». Оскільки толерантності дозволяють планувати, под може працювати на вузлах, де значення taint більше за значення толерантності. Подумайте про це так: «Я можу працювати з вузлами, які перевищують мої мінімальні вимоги».

Ці оператори працюють з числовими значеннями taint і дозволяють планувальнику приймати складні рішення щодо розміщення на основі безперервних метрик, а не дискретних категорій.

Примітка:

Числові значення для операторів Gt і Lt повинні бути додатними 64-бітними цілими числами без нулів на початку. Наприклад, "100"є дійсним, але "0100" (з нулем на початку) і "0" (нульове значення) не допускаються.

Оператори Gt і Lt працюють з усіма ефектами taint: NoSchedule, NoExecute і PreferNoSchedule.

Випадки використання та приклади

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

Приклад 1: Захист спотових інстанцій із пороговими значеннями SLA

Багато кластерів поєднують вузли на вимогу та спотові/преемптивні вузли для оптимізації витрат. Спотові вузли забезпечують значну економію, але мають вищий рівень відмов. Ви хочете, щоб більшість робочих навантажень стандартно уникало спотових вузлів, дозволяючи при цьому певним робочим навантаженням підключатися з чіткими межами SLA.

Спочатку позначте спотові вузли з їхньою ймовірністю відмови (наприклад, 15% річний рівень відмов):

apiVersion: v1
kind: Node
metadata:
  name: spot-node-1
spec:
  taints:
  - key: "failure-probability"
    value: "15"
    effect: "NoExecute"

Вузли на вимогу мають набагато нижчий рівень відмов:

apiVersion: v1
kind: Node
metadata:
  name: ondemand-node-1
spec:
  taints:
  - key: "failure-probability"
    value: "2"
    effect: "NoExecute"

Критичні робочі навантаження можуть вимагати суворих вимог до SLA:

apiVersion: v1
kind: Pod
metadata:
  name: payment-processor
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Lt"
    value: "5"
    effect: "NoExecute"
    tolerationSeconds: 30
  containers:
  - name: app
    image: payment-app:v1

Цей под буде плануватися тільки на вузлах з failure-probability менше 5 (тобто ondemand-node-1 з 2%, але не spot-node-1 з 15%). Ефект NoExecute з tolerationSeconds: 30 означає, що якщо SLA вузла погіршується (наприклад, хмарний провайдер змінює значення taint), под отримує 30 секунд для коректного завершення роботи перед примусовим виселенням.

Тим часом, відмовостійке пакетне завдання може явно вибрати спотові інстанси:

apiVersion: v1
kind: Pod
metadata:
  name: batch-job
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Lt"
    value: "20"
    effect: "NoExecute"
  containers:
  - name: worker
    image: batch-worker:v1

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

Приклад 2: Розміщення робочих навантажень ШІ за рівнями GPU

Робочі навантаження ШІ та машинного навчання часто мають специфічні вимоги до апаратного забезпечення. За допомогою операторів розширеної толерантності ви можете створювати рівні вузлів GPU та забезпечувати розміщення робочих навантажень на апаратному забезпеченні з відповідною потужністю.

Позначте вузли GPU за їхнім показником обчислювальної потужності:

apiVersion: v1
kind: Node
metadata:
  name: gpu-node-a100
spec:
  taints:
  - key: "gpu-compute-score"
    value: "1000"
    effect: "NoSchedule"
---
apiVersion: v1
kind: Node
metadata:
  name: gpu-node-t4
spec:
  taints:
  - key: "gpu-compute-score"
    value: "500"
    effect: "NoSchedule"

Велике навантаження під час тренувань може вимагати високопродуктивних графічних процесорів:

apiVersion: v1
kind: Pod
metadata:
  name: model-training
spec:
  tolerations:
  - key: "gpu-compute-score"
    operator: "Gt"
    value: "800"
    effect: "NoSchedule"
  containers:
  - name: trainer
    image: ml-trainer:v1
    resources:
      limits:
        nvidia.com/gpu: 1

Це гарантує, що под для тренування буде плануватися лише на вузлах з показником обчислювальної потужності більше 800 (наприклад, вузол A100), запобігаючи розміщенню на GPU нижчого рівня, які можуть уповільнити тренування.

Тим часом, робочі навантаження для інференсу з менш вимогливими характеристиками можуть використовувати будь-який доступний GPU:

apiVersion: v1
kind: Pod
metadata:
  name: model-inference
spec:
  tolerations:
  - key: "gpu-compute-score"
    operator: "Gt"
    value: "400"
    effect: "NoSchedule"
  containers:
  - name: inference
    image: ml-inference:v1
    resources:
      limits:
        nvidia.com/gpu: 1

Приклад 3: Розміщення робочого навантаження з оптимізацією витрат

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

Вузли можуть бути позначені їхнім рейтингом вартості:

spec:
  taints:
  - key: "cost-per-hour"
    value: "50"
    effect: "NoSchedule"

Вразливе до вартості пакетне завдання може виражати свою толерантність до дорогих вузлів:

tolerations:
- key: "cost-per-hour"
  operator: "Lt"
  value: "100"
  effect: "NoSchedule"

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

Приклад 4: Розміщення на основі продуктивності

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

tolerations:
- key: "disk-iops"
  operator: "Gt"
  value: "3000"
  effect: "NoSchedule"

Ця толерантність гарантує, що под планується тільки на вузлах, де disk-iops перевищує 3000. Оператор Gt означає «Мені потрібні вузли, які перевищують цей мінімум».

Як використовувати цю функцію

Розширені оператори толерантності є альфа-функцією в Kubernetes v1.35. Щоб спробувати її:

Увімкніть функціональнe можливість у вашому API-сервері та планувальнику:
```
--feature-gates=TaintTolerationComparisonOperators=true
```
Позначте ваші вузли числовими значеннями, що представляють метрики, релевантні для ваших потреб планування:
```
  kubectl taint nodes node-1 failure-probability=5:NoSchedule
  kubectl taint nodes node-2 disk-iops=5000:NoSchedule
```

Використовуйте нові оператори у специфікаціях ваших подів:

  spec:
    tolerations:
    - key: "failure-probability"
      operator: "Lt"
      value: "1"
      effect: "NoSchedule"

Примітка:

Оскільки це альфа-функція, розширені оператори толерантності можуть змінюватися в майбутніх випусках і їх слід використовувати з обережністю в промислових середовищах. Завжди ретельно тестуйте їх у непроизводчих кластерах.

Що далі?

Ця альфа-версія — лише початок. Збираючи відгуки від спільноти, ми плануємо:

Додати підтримку виразів CEL (Common Expression Language) у толерантності та спорідненості вузлів для ще більш гнучкої логіки планування, включаючи семантичні порівняння версій
Поліпшити інтеграцію з автоматичним масштабуванням кластерів для планування потужностей з урахуванням порогових значень
Перевести функцію в бета-версію і, зрештою, в загальну доступність із стабільністю, готовою до промислового використання

Нам особливо цікаво дізнатися про ваші випадки використання! Чи є у вас сценарії, в яких планування на основі порогових значень вирішило б проблеми? Чи є додаткові оператори або можливості, які ви хотіли б бачити?

Як долучитися

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

Ви можете звʼязатися з адміністраторами цієї функції за адресою:

Slack: #sig-scheduling у Kubernetes Slack
Список розсилки: kubernetes-sig-scheduling@googlegroups.com

З питаннями або конкретними запитаннями, повʼязаними з операторами розширеної толерантності, звертайтеся до спільноти SIG Scheduling. Чекаємо на ваші повідомлення!

Як дізнатися більше?

Заплямованість та Толерантність для розуміння основних концепцій
Оператори числового порівняння для деталей використання операторів Gt та Lt
KEP-5471: Extended Toleration Operators for Threshold-Based Placement

Kubernetes v1.35: Новий рівень ефективності завдяки перезапуску Podʼів на місці

Fri, 02 Jan 2026 10:30:00 -0800

У версії Kubernetes 1.35 представлено нову потужну функцію, яка забезпечує довгоочікувану можливість: можливість викликати повне перезавантаження Podʼів на місці. Ця функція, Restart All Containers (альфа-версія в 1.35), дозволяє ефективно скинути стан Podʼів порівняно з ресурсоємним підходом, що передбачає видалення та повторне створення всього Podʼа. Ця функція особливо корисна для робочих навантажень AI/ML, дозволяючи розробникам застосунків зосередитися на основній логіці тренування, перекладаючи складні механізми обробки збоїв і відновлення в контейнери sidecars та декларативну конфігурацію Kubernetes. За допомогою RestartAllContainers та інших запланованих вдосконалень Kubernetes продовжує додавати будівельні блоки для створення найбільш гнучких, надійних та ефективних платформ для робочих навантажень AI/ML.

Ця нова функціональність доступна після увімкнення функції RestartAllContainersOnContainerExits. Ця альфа-функція розширює функцію Правила перезапуску контейнерів, яка перейшла в бета-версію в Kubernetes 1.35.

Проблема: коли перезапуску одного контейнера недостатньо, а відтворення подів занадто дороге

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

Контейнер init готує середовище, монтуючи том або створюючи файл конфігурації. Якщо основний контейнер застосунку пошкоджує це середовище, простого перезапуску цього контейнера недостатньо. Необхідно запустити весь процес ініціалізації заново.
Watcher sidecar контролює стан системи. Якщо він виявляє невідновлюваний, але повторюваний стан помилки, він повинен ініціювати перезапуск основного контейнера застосунку з чистого аркуша.
Sidecar, який управляє віддаленим ресурсом, виходить з ладу. Навіть якщо sidecar перезапускається самостійно, основний контейнер може застрягнути, намагаючись отримати доступ до застарілого або пошкодженого зʼєднання.

У всіх цих випадках бажаною дією є перезапуск не одного контейнера, а всіх. Раніше єдиним способом досягти цього було видалення Podʼа і створення нового за допомогою контролера (наприклад, Job або ReplicaSet). Цей процес є повільним і дорогим, оскільки передбачає залучення планувальника, розподіл ресурсів вузлів та повторну ініціалізацію мережі та сховища.

Ця неефективність стає ще гіршою при обробці великомасштабних робочих навантажень AI/ML (>= 1000 вузлів з одним Podʼом на вузол). Загальною вимогою для цих синхронних робочих навантажень є те, що в разі виникнення збою (наприклад, аварії вузла) всі Podʼи у флотилії повинні бути створені заново, щоб скинути стан перед відновленням навчання, навіть якщо всі інші Podʼи не були безпосередньо уражені збоєм. Одночасне видалення, створення та планування тисяч Podʼів створює величезне вузьке місце. Орієнтовні витрати, повʼязані з цією несправністю, можуть становити 100 000 доларів на місяць у вигляді втрачених ресурсів.

Для обробки цих збоїв у завданнях навчання AI/ML потрібна складна інтеграція, що зачіпає як навчальну платформу, так і Kubernetes, які часто є нестабільними і трудомісткими. Ця функція представляє рішення, властиве Kubernetes, що покращує надійність системи і дозволяє розробникам застосунків зосередитися на основній логіці навчання.

Ще однією важливою перевагою перезапуску Podʼів на місці є те, що збереження Podʼів на призначених їм вузлах дозволяє проводити подальшу оптимізацію. Наприклад, можна реалізувати кешування на рівні вузлів, повʼязане з конкретною ідентифікацією Podʼів, що неможливо, коли Podʼи без необхідності створюються заново на різних вузлах.

Представляємо дію `RestartAllContainers`

Щоб вирішити цю проблему, у Kubernetes v1.35 додано нову дію до правил перезапуску контейнерів: RestartAllContainers. Коли контейнер завершується у спосіб, що відповідає правилу з цією дією, kubelet ініціює швидкий перезапуск Podʼа на місці.

Цей перезапуск на місці є дуже ефективним, оскільки зберігає найважливіші ресурси Podʼа:

UID, IP-адресу та мережевий простір імен Podʼа.
Пісочницю Podʼа та будь-які підключені пристрої.
Усі томи, включаючи emptyDir та томи, змонтовані з PVC.

Після завершення всіх запущених контейнерів послідовність запуску Podʼа повторно виконується з самого початку. Це означає, що всі init-контейнери запускаються знову по порядку, а потім — sidecar-контейнери та звичайні контейнери, що забезпечує повністю новий старт у відомому надійному середовищі. За винятком ефемерних контейнерів (які завершуються), всі інші контейнери, включаючи ті, що раніше були успішними або невдалими, будуть перезапущені, незалежно від їхніх індивідуальних політик перезапуску.

Випадки використання

1. Ефективний перезапуск завдань ML/Batch

Для завдань навчання ML перепланування робочого Pod у разі збою є дорогою операцією, яка марнує цінні обчислювальні ресурси. На кластері навчання з 1000 вузлів накладні витрати на перепланування можуть призвести до втрати [понад 100 000 доларів на обчислювальні ресурси щомісяця](https://docs.google.com/document/d/16zexVooHKPc80F4dVtUjDYK9DOpkVPRNfSv0zRtfFpk/edit?tab=t.0#bookmark=id. qwqcnzf96avw).

За допомогою дій RestartAllContainers ви можете вирішити цю проблему, увімкнувши набагато швидшу гібридну стратегію відновлення: відтворюйте лише «пошкоджені» Podʼи (наприклад, ті, що знаходяться на несправних вузлах), одночасно запускаючи RestartAllContainers для решти справних Podʼів. Тести показують, що це зменшує накладні витрати на відновлення з хвилин до декількох секунд.

Завдяки перезапуску на місці, watcher sidecar може контролювати основний процес навчання. Якщо він зустрічає конкретну помилку, яку можна повторити, watcher може вийти з призначеним кодом, щоб запустити швидке скидання Podʼа робітника, що дозволяє йому перезапуститися з останньої контрольної точки без залучення контролера завдань. Ця функція тепер підтримується Kubernetes.

Детальніше про майбутній розвиток та функції JobSet читайте в KEP-467 JobSet in-place restart.

apiVersion: v1
kind: Pod
metadata:
  name: ml-worker-pod
spec:
  restartPolicy: Never
  initContainers:
  # Цей контейнер ініціалізації буде перезапускатися при кожному перезапуску на місці.
  - name: setup-environment
    image: my-repo/setup-worker:1.0
  - name: watcher-sidecar
    image: my-repo/watcher:1.0
    restartPolicy: Always
    restartPolicyRules:
    - action: RestartAllContainers
      exitCodes:
        operator: In
        # Конкретний код виходу від watcher запускає повний перезапуск Podʼа.
        values: [88]
  containers:
  - name: main-application
    image: my-repo/training-app:1.0

2. Повторний запуск контейнерів init для отримання чистого стану

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

Налаштувавши основний застосунок так, щоб він завершувався з певним кодом після виявлення такого пошкодження, ви можете запустити дію RestartAllContainers, гарантуючи, що контейнер ініціалізації забезпечить чисте налаштування перед перезапуском застосунку.

3. Обробка великої кількості подібних завдань

Іноді завдання найкраще виконувати у вигляді Podʼів. Кожне завдання вимагає чіткого виконання. Завданням може бути бек-енд ігрової сесії або обробка елементів черги. Якщо швидкість виконання завдань висока, запуск повного циклу створення, планування та ініціалізації Podʼів є надто дорогим, особливо якщо завдання можуть бути короткими. Можливість перезапустити всі контейнери з нуля дозволяє Kubernetes обробляти такі сценарії без використання спеціальних рішень або фреймворків.

Як користуватися

Щоб спробувати цю функцію, ви повинні увімкнути функціональну можливість RestartAllContainersOnContainerExits у компонентах кластера Kubernetes (API-сервер та kubelet), що працюють під управлінням Kubernetes v1.35+. Ця альфа-функція розширює функцію ContainerRestartRules, яка перейшла в бета-версію в v1.35 та є стандартно увімкненою.

Після увімкнення ви можете додати restartPolicyRules до будь-якого контейнера (init, sidecar або звичайного) та використовувати дію RestartAllContainers.

Функція розроблена для зручного використання в наявних застосунках. Однак, якщо застосунок не відповідає певним рекомендаціям, це може спричинити проблеми для застосунку або інструментів спостереження. Увімкнувши цю функцію, переконайтеся, що всі контейнери є такими, що можуть бути повторно запущені, і що зовнішні інструменти готові до повторного запуску контейнерів init. Крім того, під час перезапуску всіх контейнерів kubelet не запускає хуки preStop. Це означає, що контейнери повинні бути створені таким чином, щоб витримувати раптове завершення роботи, не покладаючись на хуки preStop для коректного вимкнення.

Спостереження за перезапуском

Щоб зробити цей процес спостережуваним, до статусу Podʼа додається нова умова AllContainersRestarting. Коли перезапуск ініційовано, ця умова стає True і повертається до False, коли всі контейнери завершили роботу і Pod готовий розпочати свій життєвий цикл заново. Це забезпечує чіткий сигнал для користувачів та інших компонентів кластера про стан Podʼа.

Усі контейнери, перезапущені за допомогою цієї дії, матимуть збільшений лічильник перезапусків у статусі контейнера.

Дізнайтеся більше

Прочитайте офіційну документацію про життєвий цикл Podʼів.
Прочитайте детальну пропозицію в KEP-5532: Перезапуск усіх контейнерів при виході з контейнера.
Прочитайте пропозицію щодо перезапуску JobSet на місці в JobSet issue #467.

Ми хочемо почути вашу думку!

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

Ви можете зв’язатися з SIG Node через:

Slack: #sig-node
Mailing list

Kubernetes 1.35: Покращене відлагодження за допомогою версійованих API z-pages

Wed, 31 Dec 2025 10:30:00 -0800

Відлагодження компонентів панелі управління Kubernetes може бути складним завданням, особливо коли потрібно швидко зрозуміти стан компонента під час виконання або перевірити його конфігурацію. У Kubernetes 1.35 ми вдосконалюємо точки доступу z-pages для відлагодження за допомогою структурованих відповідей, які можна обробляти засобами машинного аналізу, що спрощує створення інструментів та автоматизацію робочих процесів з усунення несправностей.

Що таке z-сторінки?

z-сторінки — це спеціальні точки доступу для відлагодження, які надаються компонентами панелі управління Kubernetes. Введені як альфа-функція в Kubernetes 1.32, ці точки доступу забезпечують діагностику під час виконання для таких компонентів, як kube-apiserver, kube-controller-manager, kube-scheduler, kubelet та kube-proxy. Назва «z-сторінки» походить від домовленості про використання шляхів /*z (додвання останньої літери латинської абетки до шляху) для точок доступу для налагодження.

Наразі Kubernetes підтримує дві основні точки доступу z-page:

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

Ці точки доступу є корисними для операторів, яким потрібно швидко перевірити стан компонента, але дотепер вони повертали лише звичайний текст, який було важко проаналізувати програмно.

Що нового в Kubernetes 1.35?

Kubernetes 1.35 впроваджує структуровані відповіді з версіями для точок доступу /statusz та /flagz. Це вдосконалення зберігає зворотну сумісність з наявним форматом plain text, додаючи підтримку машиночитаних відповідей JSON.

Зворотньо сумісний дизайн

Нові структуровані відповіді є опціональними. Без вказання заголовка Accept точки доступу продовжують повертати звичний текстовий формат:

$ curl --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \
  --key /etc/kubernetes/pki/apiserver-kubelet-client.key \
  --cacert /etc/kubernetes/pki/ca.crt \
  https://localhost:6443/statusz

kube-apiserver statusz
Warning: This endpoint is not meant to be machine parseable, has no formatting compatibility guarantees and is for debugging purposes only.

Started: Wed Oct 16 21:03:43 UTC 2024
Up: 0 hr 00 min 16 sec
Go version: go1.23.2
Binary version: 1.35.0-alpha.0.1595
Emulation version: 1.35
Paths: /healthz /livez /metrics /readyz /statusz /version

Структуровані відповіді JSON

Щоб отримати структуровану відповідь, додайте відповідний заголовок Accept:

Accept: application/json;v=v1alpha1;g=config.k8s.io;as=Statusz

Це поверне відповідь JSON з версією:

{
  "kind": "Statusz",
  "apiVersion": "config.k8s.io/v1alpha1",
  "metadata": {
    "name": "kube-apiserver"
  },
  "startTime": "2025-10-29T00:30:01Z",
  "uptimeSeconds": 856,
  "goVersion": "go1.23.2",
  "binaryVersion": "1.35.0",
  "emulationVersion": "1.35",
  "paths": [
    "/healthz",
    "/livez",
    "/metrics",
    "/readyz",
    "/statusz",
    "/version"
  ]
}

Аналогічно, /flagz підтримує структуровані відповіді з заголовком:

Accept: application/json;v=v1alpha1;g=config.k8s.io;as=Flagz

Приклад відповіді:

{
  "kind": "Flagz",
  "apiVersion": "config.k8s.io/v1alpha1",
  "metadata": {
    "name": "kube-apiserver"
  },
  "flags": {
    "advertise-address": "192.168.8.4",
    "allow-privileged": "true",
    "authorization-mode": "[Node,RBAC]",
    "enable-priority-and-fairness": "true",
    "profiling": "true"
  }
}

Чому структуровані відповіді мають значення

Додавання структурованих відповідей відкриває кілька нових можливостей:

1. Автоматизовані перевірки стану та моніторинг

Замість аналізу простого тексту, інструменти моніторингу тепер можуть легко отримувати конкретні поля. Наприклад, ви можете програмно перевірити, чи компонент працює з несподіваною емульованою версією, або переконатися, що критичні прапорці встановлені правильно.

2. Кращі інструменти налагодження

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

3. Версії API та стабільність

Запровадивши версії API (починаючи з v1alpha1), ми забезпечуємо чіткий шлях до стабільності. У міру дозрівання функції ми запровадимо v1beta1 і, зрештою, v1, що дасть вам впевненість, що ваші інструменти не перестануть працювати з майбутніми версіями Kubernetes.

Як використовувати структуровані z-сторінки

Необхідні умови

Для обох точок доступу необхідно ввімкнути функціональні можливості:

/statusz: увімкніть функціональну можливість ComponentStatusz
/flagz: увімкніть функціональну можливість ComponentFlagz

Приклад: Отримання структурованих відповідей

Ось приклад використання curl для отримання структурованих відповідей JSON від kube-apiserver:

# Отримання структурованої відповіді statusz
curl \
  --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \
  --key /etc/kubernetes/pki/apiserver-kubelet-client.key \
  --cacert /etc/kubernetes/pki/ca.crt \
  -H «Accept: application/json;v=v1alpha1;g=config.k8s.io;as=Statusz» \
  https://localhost:6443/statusz | jq .

# Отримання структурованої відповіді flagz
curl \
  --cert /etc/kubernetes/pki/apiserver-kubelet-client.crt \
  --key /etc/kubernetes/pki/apiserver-kubelet-client.key \
  --cacert /etc/kubernetes/pki/ca.crt \
  -H «Accept: application/json;v=v1alpha1;g=config.k8s.io;as=Flagz» \
  https://localhost:6443/flagz | jq .

Примітка:

У наведених вище прикладах використовується автентифікація клієнтського сертифіката та перевіряється сертифікат сервера за допомогою --cacert. Якщо вам потрібно обійти перевірку сертифіката в тестовому середовищі, ви можете використовувати --insecure (або -k), але це ніколи не слід робити в промислових умовах, оскільки це робить вас вразливими до атак типу «зловмисник посередині» (man-in-the-middle).

Важливі зауваження

Статус альфа-функції

Структуровані відповіді z-page є альфа-функцією в Kubernetes 1.35. Це означає:

Формат API може змінитися в майбутніх версіях
Ці точки доступу призначені для відлагодження, а не для промислової автоматизації
Не слід покладатися на них для критично важливих робочих процесів моніторингу, доки вони не досягнуть бета-версії або стабільного статусу

Безпека та контроль доступу

z-сторінки розкривають інформацію про внутрішні компоненти і вимагають належного контролю доступу. Ось основні міркування щодо безпеки:

Авторизація: Доступ до точок доступу z-page обмежений членами групи system:monitoring, яка дотримується тієї ж моделі авторизації, що й для інших точок доступу для налагодження, таких як /healthz, /livez та /readyz. Це гарантує, що доступ до інформації для налагодження мають лише авторизовані користувачі та службові облікові записи. Якщо ваш кластер використовує RBAC, ви можете керувати доступом, надаючи відповідні дозволи цій групі.

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

Розкриття інформації: ці точки доступу розкривають деталі конфігурації компонентів вашого кластера, зокрема:

версії компонентів та інформацію про збірку
усі аргументи командного рядка та їхні значення (з видаленням конфіденційних значень)
доступні точки доступу для налагодження

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

Майбутня еволюція

У міру дозрівання функції ми (Kubernetes SIG Instrumentation) сподіваємося:

Впровадити версії API v1beta1 і, зрештою, v1.
Зібрати відгуки спільноти щодо схеми відповідей.
Можливо, додати додаткові точки доступу z-page на основі потреб користувачів.

Спробуйте

Ми заохочуємо вас експериментувати зі структурованими z-сторінками в тестовому середовищі:

Увімкніть функції ComponentStatusz та ComponentFlagz на компонентах вашої панелі управління.
Спробуйте надсилати запити до точок доступу як у вигляді простого тексту, так і у структурованому форматі.
Створіть простий інструмент або скрипт, який використовує структуровані дані.
Поділіться своїми відгуками зі спільнотою.

Дізнайтеся більше

Документація z-pages
KEP-4827: Статус компонента
KEP-4828: Компонент Flagz
Приєднуйтесь до обговорення в каналі #sig-instrumentation в Kubernetes Slack

Приєднуйтесь

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

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

Успішного відлагодження!

Kubernetes v1.35: Узгодження маршрутів на основі спостереження в Cloud Controller Manager

Tue, 30 Dec 2025 10:30:00 -0800

До Kubernetes v1.34 включно контролер маршрутів у реалізаціях Cloud Controller Manager (CCM), створених за допомогою бібліотеки k8s.io/cloud-provider, узгоджує маршрути через фіксований інтервал. Це призводить до непотрібних запитів до API хмарного провайдера, коли не відбуваються зміни маршрутів. Інші контролери, реалізовані через ту ж бібліотеку, вже використовують механізми на основі спостереження, використовуючи інформери для уникнення непотрібних викликів API. У версії v1.35 запроваджується нова функціональна можливість, яка дозволяє змінити поведінку контролера маршрутів на використання інформерів на основі спостереження.

Що нового?

Функціональна можливість CloudControllerManagerWatchBasedRoutesReconciliation була запроваджена у k8s.io/cloud-provider на стадії альфа-версії SIG Cloud Provider. Щоб увімкнути цю функцію, можна використовувати --feature-gate=CloudControllerManagerWatchBasedRoutesReconciliation=true у реалізації CCM, яку ви використовуєте.

Про функціональну можливість

Ця функціональна можливість запустить цикл узгодження маршрутів кожного разу, коли вузол додається, видаляється або оновлюються поля .spec.podCIDRs або .status.addresses.

Додаткове узгодження виконується через випадковий інтервал від 12 до 24 годин, який вибирається під час запуску контролера.

Ця функціональна можливість не змінює логіку в циклі узгодження. Тому користувачі реалізації CCM не повинні відчувати значних змін у своїх поточних конфігураціях маршрутів.

Як я можу дізнатися більше?

Для отримання додаткової інформації зверніться до KEP-5237.

Kubernetes v1.35: Представляємо планування з урахуванням навантаження

Mon, 29 Dec 2025 10:30:00 -0800

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

Існує багато спеціальних планувальників, пристосованих для ефективного планування робочих навантажень, але з огляду на те, наскільки поширеним і важливим є планування робочих навантажень для користувачів Kubernetes, особливо в епоху штучного інтелекту з дедалі більшою кількістю випадків використання, настав час зробити робочі навантаження першочерговим завданням для kube-scheduler і підтримувати їх нативно.

Планування з урахуванням навантаження

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

Kubernetes v1.35 представляє Workload API, який можна використовувати для опису бажаного вигляду, а також вимог до планування робочого навантаження. Він постачається з початковою реалізацією планування груп, яка наказує kube-scheduler планувати групи Podʼів за принципом все або нічого. Нарешті, ми вдосконалили планування ідентичних Podʼів (які зазвичай утворюють групи) для прискорення процесу завдяки функції ситуативного пакетування.

Workload API

Новий ресурс Workload API є частиною scheduling.k8s.io/v1alpha1 API group. Цей ресурс діє як структуроване, машиночитане визначення вимог до планування застосунку з декількома Podʼами. У той час як робочі навантаження, орієнтовані на користувача, такі як Jobs, визначають, що потрібно запустити, ресурс Workload визначає, як слід планувати групу Podʼів і як слід керувати її розміщенням протягом усього життєвого циклу.

Workload дозволяє визначити групу Podʼів і застосувати до них політику планування. Ось як виглядає конфігурація планування групи. Ви можете визначити podGroup з назвою workers і застосувати політику gang з minCount, що дорівнює 4.

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  podGroups:
  - name: workers
    policy:
      gang:
        # Група планується лише якщо одночасно можуть працювати 4 Podʼи
        minCount: 4

Коли ви створюєте свої Podʼи, ви повʼязуєте їх із цим робочим навантаженням за допомогою нового поля workloadRef:

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
  namespace: some-ns
spec:
  workloadRef:
    name: training-job-workload
    podGroup: workers
  ...

Як працює групове планування

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

Коли ви створюєте Podʼи, які є частиною групи Podʼів із груповим плануванням, втулок GangScheduling планувальника управляє життєвим циклом незалежно для кожної групи Podʼів (або ключа репліки):

Коли ви створюєте свої Podʼи (або контролер створює їх для вас), планувальник блокує їх планування, доки:
- Не буде створено обʼєкт Workload, на який є посилання.
- Посилання на групу Podʼів існує в Workload.
- Кількість очікуючих Podʼів у цій групі відповідає вашому minCount.
Коли зʼявляється достатня кількість Podʼів, планувальник намагається їх розмістити. Однак замість того, щоб відразу привʼязувати їх до вузлів, Podʼи чекають на воротах Permit.
Планувальник перевіряє, чи знайшов він дійсні призначення для всієї групи (принаймні minCount).
- Якщо для групи є місце, ворота відкриваються, і всі Podʼи привʼязуються до вузлів.
- Якщо лише частина Podʼів групи була успішно запланована протягом часу очікування (встановленого на 5 хвилин), планувальник відхиляє всі Podʼи у групі. Вони повертаються до черги, звільняючи зарезервовані ресурси для інших робочих навантажень.

Хочемо зазначити, що хоча це перша реалізація, проєкт Kubernetes має твердий намір вдосконалити та розширити алгоритм групового планування в майбутніх версіях. Серед переваг, які ми сподіваємося досягти, — фаза планування за один цикл для всієї групи, витіснення на рівні робочого навантаження та інше, що наближає нас до нашої головної мети.

Ситуативна пакетна обробка

На додачу до явного групового планування, у версії 1.35 запроваджено ситуативну пакетну обробку. Це бета-функція, яка покращує затримку планування для ідентичних Podʼів.

На відміну від групового планування, ця функція не вимагає Workload API або явного погодження з боку користувача. Вона працює ситуативно в рамках планувальника, ідентифікуючи Podʼи, які мають однакові вимоги до планування (образи контейнерів, запити на ресурси, спорідненість тощо). Коли планувальник обробляє Pod, він може повторно використовувати розрахунки здійсненності для наступних однакових Podʼів у черзі, що значно прискорює процес.

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

Обмеження

Ситуативне пакетування працює за певних умов. Усі поля, які використовує kube-scheduler для пошуку розміщення, повинні бути ідентичними між Podʼами. Крім того, використання деяких функцій вимикає механізм пакетування для цих Podʼів, щоб забезпечити правильність.

Зверніть увагу, що вам може знадобитися переглянути конфігурацію kube-scheduler, щоб переконатися, що вона не вимикає пакетну обробку для ваших робочих навантажень.

Більш детальну інформацію про обмеження дивіться в документації.

Довготривалі перспективи

Проєкт має амбітну мету — забезпечити планування з урахуванням навантаження. Ці нові API та вдосконалення планування — лише перші кроки. У найближчому майбутньому планується вирішити такі завдання:

Впровадження фази планування навантаження
Покращення підтримки багатовузлового DRA та планування з урахуванням топології
Витіснення на рівні навантаження
Покращення інтеграції між плануванням і автомасштабуванням
Покращення взаємодії із зовнішніми планувальниками робочого навантаження
Управління розміщенням робочих навантажень протягом усього їхнього життєвого циклу
Моделювання планування багатозадачного робочого навантаження

І багато іншого. Пріоритетність і порядок реалізації цих пріоритетних напрямків можуть змінюватися. Слідкуйте за подальшими оновленнями.

Початок роботи

Щоб випробувати вдосконалення планування з урахуванням навантаження:

Workload API: увімкніть функцію GenericWorkload на kube-apiserver і kube-scheduler та переконайтеся, що scheduling.k8s.io/v1alpha1 API group увімкнено.
Групове планування: увімкніть функцію GangScheduling на kube-scheduler (потрібно увімкнути Workload API).
Ситуативне пакетування: як бета-функція, вона типово ввімкнена у v1.35. Ви можете вимкнути її за допомогою функціональної можливості OpportunisticBatching на kube-scheduler, якщо потрібно.

Ми рекомендуємо вам спробувати планування з урахуванням навантаження у ваших тестових кластерах і поділитися своїм досвідом, щоб допомогти сформувати майбутнє планування Kubernetes. Ви можете надіслати свої відгуки:

Звернувшись через Slack (#sig-scheduling).
Коментуючи проблему відстеження планування з урахуванням навантаження
Створюючи новий запит у репозиторії Kubernetes.

Дізнайтеся більше

Прочитайте KEP для Workload API and gang scheduling та Ситуативна пакетна обробка.
Слідкуйте за Тікетом "Планування з урахуванням робочого навантаження" для останніх оновлень.

Kubernetes v1.35: Деталізоване управління допоміжними групами переходить в стан загальної доступності (GA)

Tue, 23 Dec 2025 10:30:00 -0800

Від імені Kubernetes SIG Node, ми раді оголосити про перехід деталізованого управління допоміжними групами до загальної доступності (GA) у Kubernetes v1.35!

Нове поле Pod supplementalGroupsPolicy було введено як opt-in альфа-функція для Kubernetes v1.31, а потім перейшло до бета у v1.33. Тепер ця функція є загальнодоступною. Ця функція дозволяє реалізувати більш точний контроль над допоміжними групами в контейнерах Linux, що може зміцнити позицію безпеки, особливо при доступі до томів. Крім того, вона також покращує прозорість деталей UID/GID у контейнерах, забезпечуючи покращений нагляд за безпекою.

Якщо ви плануєте оновити свій кластер з v1.32 або більш ранньої версії, будь ласка, зверніть увагу, що деякі зміни поведінки, що порушують сумісність, були введені з бета (v1.33). Для отримання додаткової інформації дивіться розділи змін поведінки, введених у бета та розгляди оновлення у попередньому блозі про перехід до бета.

Мотивація: Неявні членства в групах, визначені в `/etc/group` в образі контейнера

Навіть якщо більшість адміністраторів/користувачів кластерів Kubernetes можуть не бути обізнаними з цим, за звичай Kubernetes обʼєднує інформацію про групи з Podʼа з інформацією, визначеною в /etc/group в образі контейнера.

Ось приклад; маніфест Podʼа, який вказує spec.securityContext.runAsUser: 1000, spec.securityContext.runAsGroup: 3000 та spec.securityContext.supplementalGroups: 4000 як частину контексту безпеки Podʼа.

apiVersion: v1
kind: Pod
metadata:
  name: implicit-groups-example
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
  containers:
  - name: example-container
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

Який результат команди id в контейнері example-container? Вихідні дані повинні бути схожими на це:

uid=1000 gid=3000 groups=3000,4000,50000

Звідки в групі допоміжних ідентифікаторів (groups поле) зʼявився ідентифікатор групи 50000, навіть якщо 50000 взагалі не визначено в маніфесті Podʼа? Відповідь — файл /etc/group в образі контейнера.

Перевірка вмісту файлу /etc/group в образі контейнера містить щось подібне до наступного:

user-defined-in-image:x:1000:
group-defined-in-image:x:50000:user-defined-in-image

Це показує, що первинний користувач контейнера 1000 належить до групи 50000 в останньому записі.

Таким чином, членство в групі, визначене в /etc/group в образі контейнера для первинного користувача контейнера, неявно обʼєднується з інформацією з Podʼа. Будь ласка, зверніть увагу, що це було дизайнерським рішенням, яке поточні реалізації CRI успадкували від Docker, і спільнота насправді ніколи не переосмислювала це до теперішнього часу.

Що з цим не так?

Неявно обʼєднана інформація про групи з /etc/group в образі контейнера становить ризик для безпеки. Ці неявні GID не можуть бути виявлені або перевірені механізмами політики, оскільки немає запису про них у маніфесті Podʼа. Це може призвести до несподіваних проблем з контролем доступу, особливо при доступі до томів (див. kubernetes/kubernetes#112879 для деталей), оскільки дозволи файлів контролюються UID/GIDs в Linux.

Деталізоване управління допоміжними групами в Pod: `supplementaryGroupsPolicy`

Щоб вирішити цю проблему, .spec.securityContext Pod тепер включає поле supplementalGroupsPolicy.

Це поле дозволяє вам контролювати, як Kubernetes обчислює допоміжні групи для процесів контейнера всередині Podʼа. Доступні політики:

Merge: Інформація про членство в групі, визначена в /etc/group для первинного користувача контейнера, буде обʼєднана. Якщо не вказано, ця політика буде застосована (тобто типова поведінка для зворотної сумісності).
Strict: Тільки ідентифікатори груп, вказані в fsGroup, supplementalGroups або runAsGroup, прикріплюються як допоміжні групи до процесів контейнера. Членства в групах, визначені в /etc/group для первинного користувача контейнера, ігноруються.

Я поясню, як працює політика Strict. Наступний маніфест Podʼа вказує supplementalGroupsPolicy: Strict:

apiVersion: v1
kind: Pod
metadata:
  name: strict-supplementalgroups-policy-example
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
    supplementalGroupsPolicy: Strict
  containers:
  - name: example-container
    image: registry.k8s.io/e2e-test-images/agnhost:2.45
    command: [ "sh", "-c", "sleep 1h" ]
    securityContext:
      allowPrivilegeEscalation: false

Результат команди id в контейнері example-container повинен бути схожим на це:

uid=1000 gid=3000 groups=3000,4000

Ви можете побачити, що політика Strict може виключити групу 50000 з groups!

Таким чином, забезпечення supplementalGroupsPolicy: Strict (забезпечене якимось механізмом політики) допомагає запобігти неявним допоміжним групам у Podʼі.

Примітка:

Контейнер з достатніми привілеями може змінити ідентичність процесу. supplementalGroupsPolicy впливає лише на початкову ідентичність процесу.

Читайте далі для отримання додаткової інформації.

Приєднана ідентичність процесу в статусі Podʼа

Ця функція також відкриває ідентичність процесу, прикріплену до першого процесу контейнера через поле .status.containerStatuses[].user.linux. Це буде корисно, щоб побачити, чи прикріплені неявні ідентифікатори груп.

...
status:
  containerStatuses:
  - name: ctr
    user:
      linux:
        gid: 3000
        supplementalGroups:
        - 3000
        - 4000
        uid: 1000
...

Примітка:

Будь ласка, зверніть увагу, що значення в полі status.containerStatuses[].user.linux є спочатку приєднаною ідентичністю процесу до першого процесу контейнера в контейнері. Якщо контейнер має достатні привілеї для виклику системних викликів, повʼязаних з ідентичністю процесу (наприклад, setuid(2), setgid(2) або setgroups(2) тощо), процес контейнера може змінити свою ідентичність. Таким чином, фактична ідентичність процесу буде динамічною.

Існує кілька способів обмежити ці дозволи в контейнерах. Ми пропонуємо наступні як прості рішення:

встановлення privilege: false та allowPrivilegeEscalation: false у securityContext вашого контейнера, або
приведення вашого pod у відповідність до Restricted політики в Pod Security Standard.

Крім того, kubelet не має видимості у втулку NRI або внутрішній роботі середовища виконання контейнера. Адміністратор кластера, що налаштовує вузли або високо привілейовані робочі навантаження з дозволу локального адміністратора, може змінити допоміжні групи для будь-якого пода. Однак це поза сферою контролю Kubernetes і не повинно бути проблемою для вузлів з посиленою безпекою.

Політика `Strict` вимагає оновлених середовищ виконання контейнерів

Високорівневе середовище виконання контейнера (наприклад, containerd, CRI-O) відіграє ключову роль у обчисленні допоміжних ідентифікаторів груп, які будуть прикріплені до контейнерів. Таким чином, supplementalGroupsPolicy: Strict вимагає CRI-середовища, яке підтримує цю функцію. Стара поведінка (supplementalGroupsPolicy: Merge) може працювати з CRI-середовищем, яке не підтримує цю функцію, тому що ця політика є повністю зворотно сумісною.

Ось кілька CRI-середовищ, які підтримують цю функцію, і версії, які вам потрібно використовувати:

containerd: v2.0 або новіше
CRI-O: v1.31 або новіше

І ви можете побачити, чи підтримується ця функція в полі .status.features.supplementalGroupsPolicy вузла. Будь ласка, зверніть увагу, що це поле відрізняється від status.declaredFeatures, введеного в KEP-5328: Node Declared Features(formerly Node Capabilities).

apiVersion: v1
kind: Node
...
status:
  features:
    supplementalGroupsPolicy: true

Оскільки середовища виконання контейнерів універсально підтримують цю функцію, різні політики безпеки можуть почати забезпечувати поведінку Strict як більш безпечну. Найкраща практика — переконатися, що ваші Podʼи готові до цієї вимоги, і всі допоміжні групи прозоро оголошені в специфікації Podʼа, а не в образах.

Як долучитись

Це вдосконалення було ініційовано спільнотою SIG Node. Будь ласка, приєднуйтесь до нас, щоб звʼязатися зі спільнотою та поділитися своїми ідеями та відгуками щодо вищезазначеної функції та не тільки. Ми з нетерпінням чекаємо на ваші відгуки!

Як дізнатися більше?

Налаштування контексту безпеки для Podʼа або контейнера для отримання додаткової інформації про supplementalGroupsPolicy
KEP-3619: Fine-grained SupplementalGroups control

Kubernetes v1.35: Конфігурація Kubelet Drop-in Directory переходить до GA

Mon, 22 Dec 2025 10:30:00 -0800

З останнім випуском Kubernetes v1.35 стала загальнодоступною підтримка теки для конфігураційних файлів kubelet. Нова стабільна функція спрощує управління конфігурацією kubelet у великих гетерогенних кластерах.

У версії 1.35 аргумент командного рядка kubelet --config-dir готовий до використання у промислових умовах і повністю підтримується, що дозволяє вказати теку, яка містить файли конфігурації kubelet. Усі файли в цій теці будуть автоматично обʼєднані з основною конфігурацією kubelet. Це дозволяє адміністраторам кластерів підтримувати єдину базову конфігурацію для kubelet, одночасно забезпечуючи цільові налаштування для різних груп вузлів або випадків використання, без складних інструментів або ручного управління конфігурацією.

Проблема: управління конфігурацією kubelet у великому масштабі

У міру того, як кластери Kubernetes стають більшими та складнішими, вони часто включають гетерогенні пули вузлів з різними апаратними можливостями, вимогами до робочого навантаження та експлуатаційними обмеженнями. Ця різноманітність вимагає різних конфігурацій kubelet у різних групах вузлів, але управління цими різноманітними конфігураціями у великому масштабі стає все більш складним завданням. Виникає кілька проблемних моментів:

Дрейф конфігурації: різні вузли можуть мати дещо різні конфігурації, що призводить до несумісної поведінки
Налаштування групи вузлів: вузли GPU, edge вузли та стандартні обчислювальні вузли часто вимагають різних налаштувань kubelet
Операційні накладні витрати: підтримка окремих, повних файлів конфігурації для кожного типу вузла є схильною до помилок і складною для аудиту
Управління змінами: впровадження змін конфігурації в гетерогенних пулах вузлів вимагає ретельної координації

До того, як ця підтримка була додана до Kubernetes, адміністратори кластерів мали вибирати між використанням єдиного монолітного файлу конфігурації для всіх вузлів, ручним веденням декількох повних файлів конфігурації або використанням окремих інструментів. Кожен підхід мав свої недоліки. Перехід до стабільної версії надає адміністраторам кластерів повну підтримку fourth way to solve that challenge.

Приклади використання

Управління гетерогенними пулами вузлів

Розглянемо кластер із декількома типами вузлів: стандартні обчислювальні вузли, вузли з високою продуктивністю (наприклад, із графічними процесорами або великим обʼємом памʼяті) та edge вузли зі спеціальними вимогами.

Базова конфігурація

Файл: 00-base.conf

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
clusterDNS:
  - "10.96.0.10"
clusterDomain: cluster.local

Перевизначення для вузла з високою пропускною здатністю

Файл: 50-high-capacity-nodes.conf

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
maxPods: 50
systemReserved:
  memory: "4Gi"
  cpu: "1000m"

Перевизначення для edge вузлів

Файл: 50-edge-nodes.conf (edge compute typically has lower capacity)

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "5%"

Завдяки такій структурі вузли з високою пропускною здатністю застосовують як базову конфігурацію, так і перевизначення, що стосуються пропускної здатності, тоді як edge вузли застосовують базову конфігурацію з налаштуваннями, що стосуються edge.

Поступове впровадження конфігурації

Під час впровадження змін у конфігурації ви можете:

Додати новий файл із високим числовим префіксом (наприклад, 99-new-feature.conf)
Протестувати зміни на підмножині вузлів
Поступово впроваджувати зміни на інших вузлах
Після стабілізації обʼєднати зміни в базову конфігурацію

Viewing the merged configuration

Оскільки конфігурація тепер розподілена між декількома файлами, ви можете перевірити остаточну обʼєднану конфігурацію за допомогою точки доступу kubelet /configz:

# Запустіть kubectl proxy
kubectl proxy

# В іншому терміналі завантажте обʼєднану конфігурацію
# Змініть замісник “<node-name>” перед запуском команди curl
curl -X GET http://127.0.0.1:8001/api/v1/nodes/<node-name>/proxy/configz | jq .

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

Детальні інструкції з налаштування, приклади конфігурації та поведінка злиття наведені в офіційній документації:

Подяки

Ця функція була розроблена спільними зусиллями SIG Node. Особлива подяка всім учасникам, які допомогли розробити, впровадити, протестувати та задокументувати цю функцію на всіх етапах її розвитку: від альфа-версії в v1.28, бета-версії в v1.30 до загальної доступності в v1.35.

Щоб надати відгук про цю функцію, приєднайтеся до Kubernetes Node Special Interest Group, беріть участь в обговореннях в публічному каналі Slack (#sig-node) або подайте заявку на GitHub.

Приєднуйтесь

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

SIG Node буде радий дізнатися про ваш досвід використання цієї функції у виробництві!

Уникнення зомбі-учасників кластера при оновленні до etcd v3.6

Sun, 21 Dec 2025 00:00:00 +0000

Ця стаття була нещодавно опублікована в офіційному блозі etcd. Основний висновок? Завжди оновлюйтеся до etcd v3.5.26 або новішої версії перед переходом до v3.6. Це гарантує автоматичне відновлення кластера та дозволяж уникати появі зомбі-учасників.

Підсумок проблеми

Нещодавно спільнота etcd вирішила проблему, яка може виникнути, коли користувачі оновлюються з v3.5 до v3.6. Цей баг може призвести до того, що кластер повідомлятиме про "зомбі-учасників", які є вузлами etcd, що були видалені з кластера бази даних деякий час тому, і які знову зʼявляються та приєднуються до консенсусу бази даних. Кластер etcd потім стає неоперабельним, доки ці зомбі-учасники не будуть видалені.

У etcd v3.5 та раніше v2store був джерелом істини для даних про членство, навіть якщо v3store також був присутній. Як частина нашого плану припинення підтримки v2store, у v3.6 v3store стає джерелом істини для інформації про членство в кластері. Зі звіту про баг ми дізналися, що в деяких старих кластерах v2store та v3store могли стати несумісними. Ця несумісність проявляється після оновлення як поява старих, видалених "зомбі" учасників кластера, які знову зʼявляються в кластері.

Виправлення та шлях оновлення

Ми додали механізм у etcd v3.5.26 для автоматичної синхронізації v3store з v2store, гарантуючи, що уражені кластери будуть відновлені перед оновленням до 3.6.x.

Щоб підтримати багатьох користувачів, які зараз оновлюються до 3.6, ми надали наступний безпечний шлях оновлення:

Оновіть ваш кластер до v3.5.26 або пізнішої версії.
Зачекайте та підтвердіть, що всі учасники є справними після оновлення.
Оновіться до v3.6.

Ми не можемо надати безпечний обхідний шлях для користувачів, які мають перепони, що перешкоджають оновленню до v3.5.26. Таким чином, якщо v3.5.26 недоступна з вашого джерела пакунків або постачальника, ви повинні відкласти оновлення до v3.6, доки вона не стане доступною.

Додаткові технічні деталі

Інформація нижче надається лише для довідки. Користувачі можуть слідувати безпечному шляху оновлення без знання наступних деталей.

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

Супроводжувачі etcd, працюючи зі авторами повідомлення про проблему, виявили три можливі причини виникнення проблеми на основі симптомів та аналізу коду та логів etcd:

Баг у etcdctl snapshot restore (v3.4 та старих версіях): Під час відновлення знімка за допомогою etcdctl snapshot restore, etcdctl мав видалити наявих учасників перед додаванням нових. У v3.4 через баг старі учасники не були видалені, що призвело до появи зомбі-учасників. Зверніться до коментаря щодо etcdctl.
--force-new-cluster у v3.5 та попередніх версіях: У рідкісних випадках примусове створення нового кластера з одним учасником не повністю видаляло старих учасників, залишаючи зомбі. Проблема була вирішена у v3.5.22. Будь ласка, зверніться до цього PR у проєкті Raft для детальної технічної інформації.
Увімкнено --unsafe-no-sync: Якщо --unsafe-no-sync увімкнено, у рідкісних випадках etcd може зберегти зміну членства у v3store, але аварійно завершити роботу перед записом у WAL, спричиняючи несумісність між v2store та v3store. Це проблема для кластерів з одним учасником. Для кластерів з багатьма учасниками примусове створення нового кластера з одним учасником з даних аварійного вузла може призвести до появи зомбі-учасників.

Примітка

--unsafe-no-sync загалом не рекомендується, оскільки може порушити гарантії, надані протоколом консенсусу.

Важливо, що можуть бути інші причини для несумісності даних членства v2store та v3store, які ми ще не виявили. Це означає, що ви не можете припустити, що ви в безпеці лише тому, що не виконували жодної з трьох дій вище. Після оновлення користувачів до etcd v3.6 v3store стає джерелом даних про членство, і подальша несумісність неможлива.

Досвідчені користувачі, які хочуть перевірити сумісність між v2store та v3store, можуть слідувати крокам, описаним у цьому коментарі. Ця перевірка не потрібна для виправлення проблеми, і SIG etcd не рекомендує обходити оновлення v3.5.26 незалежно від результатів перевірки.

Основний висновок

Завжди оновлюйтеся до v3.5.26 або новішої версії перед переходом до v3.6. Це гарантує автоматичне відновлення кластера та уникає появі зомбі-учасників.

Подяки

Ми хотіли б подякувати Christian Baumann за повідомлення про цю давню проблему оновлення. Його звіт та подальша робота допомогли привернути нашу увагу до проблеми, щоб ми могли дослідити та вирішити її.

Kubernetes 1.35: Зміна розміру Podʼа на місці переходить у стабільний стан

Fri, 19 Dec 2025 10:30:00 -0800

Цей випуск є важливим кроком: через понад 6 років після його первинної концепції функція In-Place Pod Resize (також відома як In-Place Pod Vertical Scaling), вперше представлена як альфа-версія в Kubernetes v1.27 і переведена в бета-версію в Kubernetes v1.33, тепер є стабільною (GA) в Kubernetes 1.35!

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

Що таке In-Place Pod Resize?

В минулому, CPU та памʼять, виділені для контейнера в Pod, були незмінними. Це означало, що зміна цих ресурсів вимагала видалення та повторного створення всього Podʼа. Для stateful сервісів, batch завдань або робочих навантажень з високою чутливістю до затримки це було надзвичайно деструктивна операція.

In-Place Pod Resize робить CPU та memory requests і limits змінними, дозволяючи вам налаштовувати ці ресурси всередині запущеного Podʼа, часто без необхідності перезапуску контейнера.

Ключові концепції:

Бажані ресурси: Поле spec.containers[*].resources контейнера тепер представляє бажані ресурси. Для CPU та памʼяті ці поля тепер змінні.
Фактичні ресурси: Поле status.containerStatuses[*].resources відображає ресурси, що наразі налаштовані для запущеного контейнера.
Ініціювання зміни розміру: Ви можете вимагати зміни розміру, оновивши бажані requests і limits у специфікації Pod, використовуючи новий підресурс resize.

Як почати використовувати In-Place Pod Resize?

Докладні інструкції та приклади надані в офіційній документації: Зміна розміру CPU та memory, призначених контейнерам.

Як це допоможе мені?

In-place Pod Resize є основою для безперебійного вертикального масштабування та покращення ефективності робочих навантажень.

Ресурси, що коригуються без перебоїв Ресурси робочих навантажень, чутливих до затримок або перезапусків, можуть бути змінені на місці без простоїв або втрати стану.
Більш потужне автоматичне масштабування Автомасштабувальники тепер мають можливість коригувати ресурси з меншим впливом. Наприклад, режим оновлення InPlaceOrRecreate Vertical Pod Autoscaler (VPA), який використовує цю функцію, перейшов у стадію бета-тестування. Це дозволяє автоматично та безперебійно коригувати ресурси на основі використання з мінімальними перебоями.
- Див. AEP-4016 для отримання додаткової інформації.
Задоволення тимчасових потреб у ресурсах Робочі навантаження, які тимчасово потребують більше ресурсів, можна швидко налаштувати. Це дозволяє використовувати такі функції, як CPU Startup Boost (AEP-7862), за допомогою якої програми можуть запитувати більше ресурсів процесора під час запуску, а потім автоматично зменшувати їх.

Ось кілька прикладів використання:

Ігровий сервер, який потребує коригування розміру відповідно до кількості гравців.
Попередньо підігрітий робочий процес, який можна зменшити, коли він не використовується, але збільшити при першому запиті.
Динамічне масштабування залежно від навантаження для ефективного пакування контейнерів.
Збільшення ресурсів для JIT-компіляції під час запуску.

Зміни між бета-версією (1.33) та стабільною версією (1.35)

З моменту випуску першої бета-версії v1.33 розробники зосередилися на стабілізації функції та поліпшенні її зручності використання на основі відгуків спільноти. Ось основні зміни в стабільній версії:

Зменшення обмеження памʼяті Раніше зменшення обмежень памʼяті було заборонено. Це обмеження було знято, і тепер зменшення обмежень памʼяті дозволено. Kubelet намагається запобігти OOM-kills, дозволяючи зміну розміру тільки в тому випадку, якщо поточне використання памʼяті нижче нового бажаного обмеження. Однак ця перевірка є максимально ефективною і не гарантованою.
Зміна розміру за пріоритетом Якщо вузол не має достатньо місця для прийняття всіх запитів на зміну розміру, відкладені зміни розміру повторюються на основі такого пріоритету:
- PriorityClass
- Клас QoS
- Тривалість відкладені, причому старіші запити мають пріоритет.
Ресурси на рівні Pod (альфа) Підтримка зміни розміру Pod на місці з використанням ресурсів на рівні Podʼа була впроваджена за допомогою власної функціональної можливості, яка є альфа-версією у v1.35.
Підвищена спостережуваність: Тепер є нові метрики Kubelet та події Podʼа, які спеціально повʼязані зі зміною розміру Podʼа на місці, щоб допомогти користувачам відстежувати та налагоджувати зміни ресурсів.

Що далі?

Перехід In-Place Pod Resize до стабільної версії відкриває можливості для потужної інтеграції в екосистемі Kubernetes. Наразі планується подальше вдосконалення в декількох напрямках.

Інтеграція з автомасштабувальниками та іншими проєктами

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

Прискорення запуску VPA CPU (AEP-7862): Дозволяє застосункам запитувати більше ресурсів CPU під час запуску та зменшувати їх після певного періоду часу.
Підтримка VPA для оновлень на місці ([AEP-4016] (https://github.com/kubernetes/autoscaler/tree/455d29039bf6b1eb9f784f498f28769a8698bc21/vertical-pod-autoscaler/enhancements/4016-in-place-updates-support)): Підтримка VPA для InPlaceOrRecreate нещодавно перейшла в бета-версію, а кінцевою метою є переведення функції в стабільну версію. Підтримка режиму InPlace все ще знаходиться в стадії розробки; див. PR #8818.
Автомасштабування Ray: планується використовувати функцію In-Place Pod Resize для підвищення ефективності робочого навантаження. Дивіться цю публікацію в блозі Google Cloud для отримання додаткової інформації.
Агент-пісочниця «Soft-Pause»: Дослідження можливості використання функції Pod Resize для покращення затримки. Детальніше див. Github issue.
Підтримка середовища виконання: середовища виконання Java та Python не підтримують зміну розміру памʼяті без перезапуску. Триває відкрита дискусія з розробниками Java, див. помилку.

Якщо у вас є проєкт, який може виграти від інтеграції з функцією зміни розміру Podʼа на місці, зверніться до нас, скориставшись каналами, зазначеними в розділі зворотного звʼязку!

Розширення функціональних можливостей

Наразі функція In-Place Pod Resize заборонена при використанні в поєднанні з: swap, статичним менеджером CPU та статичним менеджером памʼяті. Крім того, ресурси, крім CPU та памʼяті, залишаються незмінними. Розширення набору підтримуваних функцій та ресурсів розглядається в міру надходження відгуків про потреби спільноти.

Також планується підтримка превентивного переривання робочого навантаження; якщо на вузлі недостатньо місця для зміни розміру під високим пріоритетом, метою є надання можливості політикам автоматично витісняти під з нижчим пріоритетом або збільшувати розмір вузла.

Покращена стабільність

Вирішення проблем з конкуренцією між kubelet і планувальником Відомі проблеми з конкуренцією між kubelet і планувальником щодо зміни розміру підсистеми на місці. Ведуться роботи з вирішення цих проблем у наступних версіях. Дивіться проблему для більш детальної інформації.
Більш безпечне зменшення обмеження памʼяті Перевірка Kubelet на запобігання OOM-kill може бути зроблена ще безпечнішою шляхом переміщення перевірки використання пам'яті в сам контейнерний runtime. Дивіться тікет для більш детальної інформації.

Надання відгуків

З метою подальшого розвитку цієї базової функції, будь ласка, поділіться своїми відгуками щодо її вдосконалення та розширення. Ви можете поділитися своїми відгуками через GitHub issues, списки розсилки або канали Slack, повʼязані зі спільнотами Kubernetes #sig-node та #sig-autoscaling.

Дякуємо всім, хто долучився до реалізації цієї довгоочікуваної функції!

Kubernetes v1.35: Завдання керовані зовнішніми контролерами переходять у загальну доступність

Thu, 18 Dec 2025 10:30:00 -0800

У Kubernetes v1.35 можливість вказати зовнішній контролер Завдань (через .spec.managedBy) переходить у загальну доступність.

Ця функція дозволяє зовнішнім контролерам брати на себе повну відповідальність за узгодження Завдань (Job), відкриваючи потужні моделі планування, такі як багатокластерне диспетчеризування з MultiKueue.

Навіщо делегувати узгодження Завдань?

Основною мотивацією для цієї функції є підтримка архітектур багатокластерного пакетного планування, таких як MultiKueue.

Архітектура MultiKueue розрізняє кластер управління та пул робочих кластерів:

Кластер управління відповідає за розподіл завдань, але не за їх виконання. Він повинен приймати обʼєкти Job для відстеження статусу, але пропускає створення та виконання Podʼів.
Кластери робочих вузлів отримують розподілені Завдання та виконують фактичні Podʼи.
Користувачі зазвичай взаємодіють із кластером управління. Оскільки статус автоматично передається назад, вони можуть спостерігати за прогресом Завдання «наживо» без доступу до кластерів робочих вузлів.
У робочих кластерах розподілені Завдання виконуються як звичайні Завдання, що управляються вбудованим контролером Завдань, без налаштування .spec.managedBy.

Використовуючи .spec.managedBy, контролер MultiKueue в кластері управління може взяти на себе узгодження Завдання. Він копіює статус із «дзеркального» Завдання, що виконується в робочому кластері, назад до кластера управління.

Чому б просто не вимкнути контролер завдань? Хоча теоретично це можна зробити, повністю вимкнувши вбудований контролер Завдань, часто це неможливо або недоцільно з двох причин:

Панелі управління, керовані постачальником: у багатьох хмарних середовищах панель управління Kubernetes заблокована, і користувачі не можуть змінювати прапорці менеджера контролера.
Гібридна роль кластера: користувачам часто потрібен «гібридний» режим, в якому кластер управління надсилає деякі важкі робочі навантаження до віддалених кластерів, але все одно виконує менші завдання або завдання, повʼязані з панеллю управління, в кластері управління. .spec.managedBy дозволяє таку деталізацію для кожного завдання окремо.

Як працює `.spec.managedBy`

Поле .spec.managedBy вказує, який контролер відповідає за Завдання. Існує два режими роботи:

Standard: якщо не встановлено або встановлено на зарезервоване значення kubernetes.io/job-controller, вбудований контролер Job узгоджує завдання як зазвичай (стандартна поведінка).
Delegation: якщо встановлено на будь-яке інше значення, вбудований контролер Job повністю пропускає узгодження для цього завдання.

Щоб запобігти появі осиротілих Podʼів або витоку ресурсів, це поле є незмінним. Ви не можете перенести запущене завдання з одного контролера на інший.

Якщо ви плануєте впровадити зовнішній контролер, майте на увазі, що ваш контролер повинен відповідати визначенням Job API. Для забезпечення відповідності значну частину зусиль було спрямовано на впровадження розширених правил перевірки статусу завдання. Перейдіть до розділу Як дізнатися більше? для отримання додаткової інформації.

Впровадження в екосистему

Поле .spec.managedBy швидко стає стандартним інтерфейсом для делегування контролю в екосистемі пакетної обробки Kubernetes.

Різні власні контролери робочого навантаження додають це поле (або його еквівалент), щоб MultiKueue міг перейняти їх узгодження та координувати їх між кластерами:

Хоча можна використовувати .spec.managedBy для реалізації власного контролера завдань з нуля, ми ще не спостерігали такого. Ця функція спеціально розроблена для підтримки моделей делегування, таких як MultiKueue, без необхідності винаходити велосипед.

Як дізнатися більше?

Якщо ви хочете дізнатися більше:

Прочитайте документацію для користувачів щодо:

Детальний огляд історії розробки:

Пропозиція щодо вдосконалення Kubernetes (KEP) Механізм управління завданнями, включаючи впровадження розширених Правил перевірки статусу завдань.
Kueue KEP для MultiKueue.

Дізнайтеся, як MultiKueue використовує .spec.managedBy на практиці, у посібнику з виконання завдань для виконання завдань у кластерах.

Подяки

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

Ми хотіли б особливо подякувати:

Мацею Шуліку — за керівництво, наставництво та рецензії.
Філіпу Крєпінському — за наставництво, допомогу та рецензії.

Приєднуйтесь

Ця робота була спонсорована Kubernetes Batch Working Group у тісній співпраці з SIG Apps та за активної підтримки спільноти SIG Scheduling.

Якщо ви зацікавлені в пакетному плануванні, рішеннях для декількох кластерів або подальшому вдосконаленні Job API:

Приєднуйтесь до нас на засіданнях Batch WG та SIG Apps.
Підпишіться на WG Batch Slack channel.

Kubernetes v1.35: Timbernetes («Світове дерево»)

Wed, 17 Dec 2025 10:30:00 -0800

Редактори: Aakanksha Bhende, Arujjwal Negi, Chad M. Crowell, Graziano Casto, Swathi Rao

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

Цей випуск містить 60 вдосконалень, включаючи 17 стабільних, 19 бета- та 22 альфа-функції.

У цьому випуску також є деякі застарілі та видалені функції; обовʼязково ознайомтеся з ними.

Тема та логотип релізу

2025 рік розпочався у сяйві Octarine: The Color of Magic (v1.33) і промайнув під поривами Of Wind & Will (v1.34). Ми завершуємо цей рік, тримаючись за Світове дерево, натхненні Іггдрасілем, деревом життя, що поєднує багато світів. Як і будь-яке велике дерево, Kubernetes росте кільце за кільцем і реліз за релізом, формуючись під опікою глобальної спільноти.

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

Три білки охороняють дерево: чарівник, що тримає сувій LGTM для рецензентів, воїн із сокирою та щитом Kubernetes для команд, що випускають нові версії та створюють нові гілки, та розбійник із ліхтарем для сортувальників, які проливають світло на темні черги проблем.

Разом вони складають набагато більшу групу шукачів пригод. Kubernetes v1.35 додає ще одне кільце росту до Світового дерева, свіжий зріз, сформований багатьма руками, багатьма шляхами та спільнотою, гілки якої досягають все більших висот, а коріння — все більшої глибини.

Основні оновлення

Kubernetes v1.35 містить безліч нових функцій та вдосконалень. Ось кілька оновлень, на які команда розробників хотіла б звернути вашу увагу!

Stable: Оновлення ресурсів Podʼів на місці

Kubernetes перевів оновлення ресурсів Podʼів на місці в статус загальної доступності (GA). Ця функція дозволяє користувачам налаштовувати ресурси CPU та памʼяті без перезапуску Podʼів або контейнерів. Раніше такі зміни вимагали повторного створення Podʼів, що могло порушити робочі процеси, особливо для застосунків із збереженням стану або пакетних застосунків. У попередніх версіях Kubernetes можна було змінювати лише налаштування ресурсів інфраструктури (запити та обмеження) для поточних Podʼів. Новий функціонал дозволяє здійснювати більш плавне вертикальне масштабування без перебоїв, підвищує ефективність, а також спрощує розробку.

Ця робота була виконана в рамках KEP #1287 під керівництвом SIG Node.

Beta: Сертифікати Podʼів для ідентифікації та безпеки робочого навантаження

Раніше для доставки сертифікатів до Podʼів були потрібні зовнішні контролери (cert-manager, SPIFFE/SPIRE), оркестрування CRD та управління Secret, а ротація здійснювалася за допомогою sidecarʼів або init-контейнерів. Kubernetes v1.35 забезпечує вбудовану ідентифікацію робочого навантаження з автоматизованою ротацією сертифікатів, що значно спрощує використання сервісних мереж та архітектур нульової довіри.

Тепер kubelet генерує ключі, запитує сертифікати через PodCertificateRequest і записує пакети облікових даних безпосередньо у файлову систему Podʼа. kube-apiserver застосовує обмеження вузлів під час допуску, усуваючи найпоширенішу пастку для сторонніх підписантів: випадкове порушення меж ізоляції вузлів. Це забезпечує чисті потоки mTLS без токенів на предʼявника у шляху видачі.

Ця робота була виконана в рамках KEP #4317 під керівництвом SIG Auth.

Alpha: Функції, що декларуються вузлом перед плануванням

Коли панелі управління вмикають нові функції, але вузли відстають (дозволено політикою Kubernetes skew), планувальник може розміщувати podʼи, що потребують цих функцій, на несумісних старих вузлах. Фреймворк оголошення функцій вузлів дозволяє вузлам декларувати підтримувані ними функції Kubernetes. З увімкненою новою альфа-можливістю вузол повідомляє про функції, які він підтримує, публікуючи цю інформацію в панелі управління через нове поле .status.declaredFeatures. Потім kube-scheduler, контролери допуску та сторонні компоненти можуть використовувати ці декларації. Наприклад, ви можете застосувати обмеження планування та перевірки API, щоб гарантувати, що Podʼи працюють тільки на сумісних вузлах.

Ця робота була виконана в рамках KEP #5328 під керівництвом SIG Node.

Функції, що перейшли в стабільний стан

Це підбірка деяких поліпшень, які тепер є стабільними після випуску версії 1.35.

Розподіл трафіку PreferSameNode

Поле trafficDistribution для Services було оновлено, щоб забезпечити більш чіткий контроль за маршрутизацією трафіку. Було додано нову опцію PreferSameNode, яка дозволяє сервісам суворо пріоритезувати точки доступу на локальному вузлі, якщо вони доступні, а в іншому випадку переходити на віддалені точки доступу.

Одночасно наявну опцію PreferClose було перейменовано на PreferSameZone. Ця зміна робить API зрозумілішим, чітко вказуючи, що трафік переважно проходить у межах поточної зони доступності. Хоча PreferClose збережено для зворотної сумісності, PreferSameZone тепер є стандартом для зональної маршрутизації, що забезпечує чітке розмежування пріоритетів на рівні вузлів і на рівні зон.

Ця робота була виконана в рамках KEP #3015 під керівництвом SIG Network.

Механізм управління Job API

Job API тепер включає поле managedBy, яке дозволяє зовнішньому контролеру обробляти синхронізацію статусу Job. Ця функція, яка перейшла в стабільний стан у Kubernetes v1.35, в першу чергу реалізована за допомогою MultiKueue — системи диспетчеризації для декількох кластерів, в якій Job, створений в кластері управління, дзеркально відображається і виконується в робочому кластері, а оновлення статусу передаються назад. Щоб уможливити цей робочий процес, вбудований контролер Job не повинен діяти на конкретний ресурс Job, щоб контролер Kueue міг замість цього керувати оновленнями статусу.

Метою є забезпечення чіткого делегування синхронізації завдань іншому контролеру. Мета не полягає в передачі власних параметрів користувачів цьому контролеру або зміні політик паралельності CronJob.

Ця робота була виконана в рамках KEP #4368 під керівництвом SIG Apps.

Надійне відстеження оновлень Podʼів за допомогою `.metadata.generation`

Історично, в API Pod не було поля metadata.generation, яке є в інших обʼєктах Kubernetes, таких як Deployments. Через це контролери та користувачі не мали надійного способу перевірити, чи kubelet дійсно обробив останні зміни в специфікації Podʼа. Ця неоднозначність була особливо проблематичною для таких функцій, як вертикальне масштабування Podʼів на місці, де було важко точно визначити, коли було виконано запит на зміну розміру ресурсу.

У Kubernetes v1.33 було додано поля .metadata.generation для Podʼів як альфа-функція. Це поле тепер є стабільним у Pod API v1.35, що означає, що кожного разу, коли оновлюється spec Podʼа, значення .metadata.generation збільшується. В рамках цього вдосконалення Pod API також отримав поле .status.observedGeneration, яке повідомляє про покоління, яке kubelet успішно побачив і обробив. Умови Podʼів також містять власне індивідуальне поле observedGeneration, яке клієнти можуть повідомляти та/або спостерігати.

Оскільки ця функція стала стабільною у v1.35, вона доступна для всіх робочих навантажень.

Ця робота була виконана в рамках KEP #5067 під керівництвом SIG Node.

Настроюваний ліміт NUMA-вузлів для менеджера топології

Історично менеджер топології використовував жорстко заданий ліміт у 8 для максимальної кількості NUMA-вузлів, які він може підтримувати, запобігаючи вибуху стану під час обчислення спорідненості. (Тут є важлива деталь: вузол NUMA не є тим самим, що й вузол у API Kubernetes.) Це обмеження кількості вузлів NUMA заважало Kubernetes повною мірою використовувати сучасні високопродуктивні сервери, які все частіше оснащуються архітектурами ЦП з більш ніж 8 вузлами NUMA.

У Kubernetes v1.31 було введено нову опцію beta max-allowable-numa-nodes для конфігурації політики менеджера топології. У Kubernetes v1.35 ця опція є стабільною. Адміністратори кластерів, які її вмикають, можуть використовувати сервери з більш ніж 8 вузлами NUMA.

Хоча опція конфігурації є стабільною, спільнота Kubernetes усвідомлює низьку продуктивність великих хостів NUMA, і існує пропозиція щодо вдосконалення (KEP-5726), яка має на меті її покращити. Більше про це можна дізнатися, прочитавши Політики управління топологією на вузлі.

Ця робота була виконана в рамках KEP #4622 під керівництвом SIG Node.

Нові функції в бета-версії

Це підбірка деяких поліпшень, які зараз знаходяться в бета-версії після випуску v1.35.

Експонування міток топології вузлів через Downward API

Для доступу до інформації про топологію вузлів, такої як регіон і зона, зсередини Podʼа зазвичай потрібно було надсилати запит до сервера Kubernetes API. Хоча цей підхід є функціональним, він створює складності та ризики для безпеки, оскільки вимагає широких дозволів RBAC або sidecar-контейнерів лише для отримання метаданих інфраструктури. Kubernetes v1.35 просуває можливість експонування міток топології вузлів безпосередньо через Downward API до бета-версії.

Тепер kubelet може робити інʼєкцію стандартних міток топології, таких як topology.kubernetes.io/zone та topology.kubernetes.io/region, у Pod як змінні середовища або у файли спроєцьоованих томів. Основна перевага полягає в більш безпечному та ефективному способі забезпечення топологічної обізнаності робочих навантажень. Це дозволяє застосункам природно адаптуватися до своєї зони доступності або регіону без залежності від API-сервера, посилюючи безпеку завдяки дотриманню принципу мінімальних привілеїв та спрощуючи конфігурацію кластера.

Примітка: Kubernetes тепер робить інʼєкцію доступних міток топології в кожен Pod, щоб їх можна було використовувати як вхідні дані для downward API. З оновленням до версії v1.35 більшість адміністраторів кластерів побачать кілька нових міток, доданих до кожного Podʼа; це очікується як частина дизайну.

Ця робота була виконана в рамках KEP #4742 під керівництвом SIG Node.

Вбудована підтримка міграції версій сховища

У Kubernetes v1.35 вбудована підтримка міграції версій сховища перейшла в стадію бета-тестування і є типово увімкненою. Цей крок інтегрує логіку міграції безпосередньо в основну панелі управління Kubernetes («in-tree»), усуваючи залежність від зовнішніх інструментів.

Раніше адміністратори покладалися на ручні «цикли читання/запису», часто підключаючи kubectl get до kubectl replace для оновлення схем або повторного шифрування даних у стані спокою. Цей метод був неефективним і схильним до конфліктів, особливо для великих ресурсів, таких як Secrets. У цій версії вбудований контролер автоматично обробляє конфлікти оновлень і токени узгодженості, забезпечуючи безпечний, оптимізований і надійний спосіб гарантувати актуальність збережених даних з мінімальними оперативними витратами.

Ця робота була виконана в рамках KEP #4192 під керівництвом SIG API Machinery.

Обмеження приєднання змінюваних томів

Драйвер CSI (Container Storage Interface) — це втулок Kubernetes, який забезпечує послідовний спосіб підключення систем зберігання даних до контейнеризованих робочих навантажень. Обʼєкт CSINode записує детальну інформацію про всі драйвери CSI, встановлені на вузлі. Однак може виникнути невідповідність між заявленою та фактичною ємністю на вузлах. Коли після запуску драйвера CSI використовуються слоти томів, kube-scheduler може призначити podʼи зі збереженням стану вузлам без достатньої ємності, що в решті решт призведе до зависання в стані ContainerCreating.

Kubernetes v1.35 робить CSINode.spec.drivers[*].allocatable.count змінним, щоб доступна ємність підключення томів вузла могла оновлюватися динамічно. Це також дозволяє драйверам CSI контролювати частоту оновлення значення allocatable.count на всіх вузлах шляхом введення настроюваного інтервалу оновлення, визначеного через обʼєкт CSIDriver. Крім того, він автоматично оновлює CSINode.spec.drivers[*].allocatable.count при виявленні збою в підключенні томів через недостатню ємність. Хоча ця функція перейшла в бета-версію в v1.34 з функціональною можливістю MutableCSINodeAllocatableCount, яка є типово вимкненою, вона залишається в бета-версії для v1.35, щоб дати час для відгуків, але функціональна можливість є типово увімкненою.

Ця робота була виконана в рамках KEP #4876 під керівництвом SIG Storage.

Випадкова пакетна обробка

Історично склалося так, що планувальник Kubernetes обробляє поди послідовно з часовою складністю O(num pods × num nodes), що може призвести до надмірних обчислень для сумісних подів. Цей KEP вводить механізм випадкової пакетної обробки, який має на меті покращити продуктивність шляхом ідентифікації таких сумісних подів за допомогою Pod scheduling signature та їх пакетної обробки, що дозволяє застосовувати спільні результати фільтрування та оцінювання до всіх них.

Підпис планування подів гарантує, що два поди з однаковим підписом є «однаковими» з точки зору планування. Він враховує не тільки атрибути подів і вузлів, але й інші поди в системі та глобальні дані про розміщення подів. Це означає, що будь-який под із заданим підписом отримає однакові результати оцінки/реалістичності від будь-якого довільного набору вузлів.

Механізм обʼєднання складається з двох операцій, які можна викликати в будь-який час, коли це необхідно — create та nominate. Create призводить до створення нового набору інформації про пакет на основі результатів планування Podʼів, які мають дійсний підпис. Nominate використовує інформацію про пакет з create, щоб встановити імʼя номінованого вузла з нового Podʼа, підпис якого відповідає канонічному підпису Podʼа.

Ця робота була виконана в рамках KEP #5598 під керівництвом SIG Scheduling.

`maxUnavailable` для StatefulSets

StatefulSet запускає групу Podʼів і підтримує фіксовану ідентичність для кожного з них. Це критично важливо для робочих навантажень із збереженням стану, які вимагають стабільних мережевих ідентифікаторів або постійного зберігання. Коли .spec.updateStrategy.<type> StatefulSet встановлено на RollingUpdate, контролер StatefulSet видалить і перестворить кожен Pod у StatefulSet. Він буде діяти в тому ж порядку, що і при припиненні роботи Podʼів (від найбільшого порядкового номера до найменшого), оновлюючи кожен Pod по черзі.

У Kubernetes v1.24 до налаштувань конфігурації rollingUpdate StatefulSet додано нове поле alpha з назвою maxUnavailable. Це поле не було частиною API Kubernetes, якщо адміністратор кластера явно не вибрав його. У Kubernetes v1.35 це поле є бета-версією і є стандартно доступним. Ви можете використовувати його для визначення максимальної кількості Podʼів, які можуть бути недоступними під час оновлення. Це налаштування є найбільш ефективним у поєднанні з .spec.podManagementPolicy, встановленим на Parallel. Ви можете встановити maxUnavailable як додатне число (наприклад: 2) або відсоток від бажаної кількості Podʼів (наприклад: 10%). Якщо це поле не вказано, стандартно буде встановлено значення 1, щоб зберегти попередню поведінку оновлення лише одного пода за раз. Це вдосконалення дозволяє застосункам зі збереженням стану (які можуть терпіти відмову більше ніж одного пода) швидше завершувати оновлення.

Ця робота була виконана в рамках KEP #961 під керівництвом SIG Apps.

Настроювана політика втулків для облікових даних у `kuberc`

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

У рамках випуску v1.35 kuberc отримує додаткову функціональність, яка дозволяє користувачам налаштовувати політику втулків для облікових даних. Ця зміна вводить два поля credentialPluginPolicy, яке дозволяє або забороняє всі втулки, та дозволяє вказати список дозволених втулків за допомогою credentialPluginAllowlist.

Ця робота була виконана в рамках KEP #3104 у співпраці між SIG Auth та SIG CLI.

KYAML

YAML — це формат серіалізації даних, зрозумілий для людини. У Kubernetes файли YAML використовуються для визначення та конфігурації ресурсів, таких як Pods, Services та Deployments. Однак складний YAML важко читати. Значні пробіли в YAML вимагають ретельної уваги до відступів та вкладеності, а опціональне цитування рядків може призвести до несподіваного примусового перетворення типів (див.: The Norway Bug). Хоча JSON є альтернативою, він не підтримує коментарі та має суворі вимоги до кінцевих ком та цитованих ключів.

KYAML — це безпечніший та менш неоднозначний піднабір YAML, розроблений спеціально для Kubernetes. Введена як опціональна альфа-функція у версії 1.34, ця функція перейшла у бета-версію в Kubernetes 1.35 і стала стандартно увімкненою. Її можна вимкнути, встановивши змінну середовища KUBECTL_KYAML=false.

KYAML вирішує проблеми, повʼязані як з YAML, так і з JSON. Усі файли KYAML також є дійсними файлами YAML. Це означає, що ви можете писати KYAML і передавати його як вхідні дані до будь-якої версії kubectl. Це також означає, що вам не потрібно писати в суворому KYAML, щоб вхідні дані були розібрані.

Ця робота була виконана в рамках KEP #5295 під керівництвом SIG CLI.

Настроювана толерантність для HorizontalPodAutoscalers

Horizontal Pod Autoscaler (HPA) історично покладався на фіксовану глобальну толерантність 10% для дій з масштабування. Недоліком цього жорстко заданого значення було те, що робочі навантаження, які вимагають високої чутливості, наприклад ті, що потребують масштабування при збільшенні навантаження на 5%, часто блокувалися, тоді як інші могли коливатися без необхідності.

У Kubernetes v1.35 функція настроюваної толерантності перейшла в бета-версію і є стандартно увімкненою. Це вдосконалення дозволяє користувачам визначати власне вікно толерантності для кожного ресурсу в полі HPA behavior. Встановивши конкретну толерантність (наприклад, знизивши її до 0,05 для 5%), оператори отримують точний контроль над чутливістю автомасштабування, забезпечуючи швидку реакцію критичних робочих навантажень на невеликі зміни метрик без необхідності коригування конфігурації всього кластера.

Ця робота була виконана в рамках KEP #4951 під керівництвом SIG Autoscaling.

Підтримка просторів імен користувачів у Podʼах

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

Ця робота була виконана в рамках KEP #127 під керівництвом SIG Node.

VolumeSource: артефакт OCI та/або образ

Під час створення Podʼа часто потрібно надати дані, бінарні файли або файли конфігурації для контейнерів. Це означало включення вмісту в основний образ контейнера або використання спеціального контейнера init для завантаження та розпакування файлів у emptyDir. Обидва ці підходи залишаються дійсними. У Kubernetes v1.31 додано підтримку типу томів image, що дозволяє Podʼам декларативно витягувати та розпаковувати артефакти образу контейнера OCI у том. Це дозволяє пакувати та доставляти артефакти, що містять лише дані, такі як конфігурації, бінарні файли або моделі машинного навчання, використовуючи стандартні інструменти реєстру OCI.

Завдяки цій функції ви можете повністю відокремити свої дані від образу контейнера та усунути необхідність у додаткових контейнерах ініціалізації або скриптах запуску. Тип тома image перебуває в бета-версії з v1.33 і є стандартно увімкненим у v1.35. Зверніть увагу, що для використання цієї функції потрібен сумісний рушій виконання контейнерів, такий як containerd v2.1 або пізнішої версії.

Ця робота була виконана в рамках KEP #4639 під керівництвом SIG Node.

Примусова перевірка облікових даних `kubelet` для кешованих образів

Налаштування imagePullPolicy: IfNotPresent наразі дозволяє Podʼу використовувати образ контейнера, який вже кешований на вузлі, навіть якщо сам Pod не має облікових даних для отримання цього образу. Недоліком такої поведінки є те, що вона створює вразливість безпеки в багатокористувацьких кластерах: якщо Pod з дійсними обліковими даними отримує конфіденційний приватний образ на вузол, наступний неавторизований Pod на тому самому вузлі може отримати доступ до цього образу, просто використовуючи локальний кеш.

Цей KEP вводить механізм, за допомогою якого kubelet забезпечує перевірку облікових даних для кешованих образів. Перш ніж дозволити Podʼу використовувати локально кешований образ, kubelet перевіряє, чи має Pod дійсні облікові дані для його отримання. Це гарантує, що тільки авторизовані робочі навантаження можуть використовувати приватні образи, незалежно від того, чи вже присутні вони на вузлі, що значно посилює безпеку спільних кластерів.

У Kubernetes v1.35 ця функція перейшла в бета-версію і є стандартно увімкненою. Користувачі все ще можуть вимкнути її, встановивши для функції KubeletEnsureSecretPulledImages значення false. Крім того, прапорець imagePullCredentialsVerificationPolicy дозволяє операторам налаштувати бажаний рівень безпеки, від режиму, що надає пріоритет зворотній сумісності, до режиму суворого виконання, що забезпечує максимальну безпеку.

Ця робота була виконана в рамках KEP #2535 під керівництвом SIG Node.

Деталізовані правила перезапуску контейнерів

Історично поле restartPolicy визначалося суворо на рівні Podʼа, що змушувало всі контейнери в Podʼі поводитися однаково. Недоліком цього глобального налаштування була відсутність деталізації для складних робочих навантажень, таких як завдання навчання AI/ML. Вони часто вимагали restartPolicy: Never для управління завершенням завдань Podʼа, але окремі контейнери могли б скористатися перевагами перезапуску на місці для конкретних помилок, які можна повторити (наприклад, збої мережі або помилки ініціалізації GPU).

Kubernetes v1.35 вирішує цю проблему, увімкнувши restartPolicy та restartPolicyRules у самому API контейнера. Це дозволяє користувачам визначати стратегії перезапуску для окремих звичайних та ініціалізаційних контейнерів, які працюють незалежно від загальної політики Podʼа. Наприклад, контейнер тепер можна налаштувати так, щоб він автоматично перезапускався тільки в разі виходу з певним кодом помилки, що дозволяє уникнути значних витрат на перепланування всього Podʼа через тимчасові збої.

У цій версії функція перейшла в бета-версію і є типово увімкненою. Користувачі можуть негайно використовувати restartPolicyRules у своїх специфікаціях контейнерів, щоб оптимізувати час відновлення та використання ресурсів для довготривалих робочих навантажень, не змінюючи загальну логіку життєвого циклу своїх Podʼів.

Ця робота була виконана в рамках KEP #5307 під керівництвом SIG Node.

Включення драйвера CSI для токенів службових облікових записів через поле секретів

Надання токенів ServiceAccount драйверам Container Storage Interface (CSI) традиційно базувалося на їх інʼєкції у поле volume_context. Такий підхід становить значний ризик для безпеки, оскільки volume_context призначене для нечутливих даних конфігурації і часто реєструється драйверами та інструментами налагодження у вигляді звичайного тексту, що може призвести до витоку облікових даних.

Kubernetes v1.35 впроваджує механізм опції для драйверів CSI, що дозволяє отримувати токени ServiceAccount через спеціальне поле секретів у запиті NodePublishVolume. Тепер драйвери можуть увімкнути цю функцію, встановивши поле serviceAccountTokenInSecrets на значення true у своєму обʼєкті CSIDriver, даючи вказівку kubelet безпечно заповнити токен.

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

Ця робота була виконана в рамках KEP #5538 під керівництвом SIG Auth у співпраці з SIG Storage.

Стан Deployment: кількість реплік, що завершують роботу

Раніше стан Deployment надавав детальну інформацію про доступні та оновлені репліки, але не містив чіткої інформації про Podʼи, які перебували в процесі вимкнення. Недоліком такого упущення було те, що користувачі та контролери не могли легко відрізнити стабільний Deployment від такого, в якому Podʼи все ще виконували завдання з очищення або дотримувалися тривалих пільгових періодів.

Kubernetes v1.35 переводить поле terminatingReplicas у статусі Deployment у статус бета-версії. Це поле надає кількість Podʼів, для яких встановлено час видалення, але які ще не були видалені з системи. Ця функція є фундаментальним кроком у більш масштабній ініціативі щодо поліпшення способу обробки заміни Podʼів у Deployments, що закладає основу для майбутніх політик щодо створення нових Podʼів під час розгортання.

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

Ця робота була виконана в рамках KEP #3973 під керівництвом SIG Apps.

Нові функції в альфа-версії

Це підбірка деяких поліпшень, які зараз знаходяться в альфа-версії після випуску v1.35.

Підтримка групового планування в Kubernetes

Планування взаємозалежних робочих навантажень, таких як завдання з навчання AI/ML або HPC-симуляції, традиційно було складним завданням, оскільки стандартний планувальник Kubernetes розміщує Podʼи індивідуально. Це часто призводить до часткового планування, коли деякі Podʼи запускаються, а інші безкінечно чекають на ресурси, що призводить до тупикових ситуацій і марнування потужності кластера.

Kubernetes v1.35 впроваджує вбудовану підтримку так званого «планування груп» за допомогою нового API робочого навантаження та концепції PodGroup. Ця функція реалізує стратегію планування «все або нічого», гарантуючи, що визначена група Podʼів планується тільки в тому випадку, якщо кластер має достатньо ресурсів для одночасного розміщення всієї групи.

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

Ця робота була виконана в рамках KEP #4671 під керівництвом SIG Scheduling.

Обмежена імперсонізація

Історично, дієслово impersonate в Kubernetes RBAC функціонувало за принципом «все або нічого»: як тільки користувач отримував дозвіл на наслідування цільової ідентичності, він отримував усі повʼязані з нею дозволи. Недоліком такого широкого дозволу було порушення принципу мінімальних привілеїв, що не дозволяло адміністраторам обмежувати дії або ресурси, доступні для імперсоніфікаторів.

Kubernetes v1.35 впроваджує нову альфа-функцію, обмежене наслідування, яка додає вторинну перевірку авторизації до процесу наслідування. Коли ця функція вмикається через функціональну можливість ConstrainedImpersonation, API-сервер перевіряє не тільки базовий дозвіл impersonate, але й перевіряє, чи уповноважений імітатор на конкретну дію, використовуючи нові префікси дієслів (наприклад, impersonate-on:<mode>:<verb>). Це дозволяє адміністраторам визначати детальні політики, наприклад, дозволяти інженеру технічної підтримки імітувати адміністратора кластера виключно для перегляду журналів, не надаючи повного адміністративного доступу.

Ця робота була виконана в рамках KEP #5284 під керівництвом SIG Auth.

Flagz для компонентів Kubernetes

Для перевірки конфігурації компонентів Kubernetes, таких як API-сервер або kubelet, традиційно був необхідний привілейований доступ до вузла хоста або аргументів процесу. Щоб вирішити цю проблему, було введено кінцеву точку доступу /flagz для експонування опцій командного рядка через HTTP. Однак спочатку її вивід був обмежений простим текстом, що ускладнювало автоматизованим інструментам надійний аналіз і перевірку конфігурацій.

У Kubernetes v1.35 точка доступу /flagz була вдосконалена для підтримки структурованого, машиночитаного виводу JSON. Авторизовані користувачі тепер можуть запитувати версійну відповідь JSON за допомогою стандартного узгодження вмісту HTTP, тоді як оригінальний формат простого тексту залишається доступним для перевірки людиною. Це оновлення значно покращує спостережуваність і робочі процеси відповідності, дозволяючи зовнішнім системам програмно перевіряти конфігурації компонентів без нестабільного аналізу тексту або прямого доступу до інфраструктури.

Ця робота була виконана в рамках KEP #4828 під керівництвом SIG Instrumentation.

Statusz для компонентів Kubernetes

Для відладки компонентів Kubernetes, таких як kube-apiserver або kubelet, традиційно використовувався аналіз неструктурованих журналів або текстового виводу, що було ненадійним і важким для автоматизації. Хоча попередньо існувала базова кінцева точка /statusz, вона не мала стандартизованого, машиночитаного формату, що обмежувало її корисність для зовнішніх систем моніторингу.

У Kubernetes v1.35 кінцева точка /statusz була покращена для підтримки структурованого, машиночитаного JSON-виводу. Авторизовані користувачі тепер можуть запитувати цей формат за допомогою стандартного узгодження вмісту HTTP, щоб отримати точні дані про стан, такі як інформація про версію та показники справності без залежності на хрупкому аналізуванні тексту. Це покращення забезпечує надійний, узгоджений інтерфейс для автоматизованих інструментів налагодження та спостережуваності у всіх основних компонентах.

Ця робота була виконана в рамках KEP #4827 під керівництвом SIG Instrumentation.

CCM: узгодження контролера маршрутів на основі спостереження за допомогою інформерів

Управління мережевими маршрутами в хмарних середовищах традиційно базувалося на періодичному опитуванні API хмарного провайдера за допомогою Cloud Controller Manager (CCM) для перевірки та оновлення таблиць маршрутів. Цей підхід узгодження з фіксованим інтервалом може бути неефективним, часто генеруючи великий обсяг непотрібних викликів API та створюючи затримку між зміною стану вузла та відповідним оновленням маршруту.

Для версії Kubernetes v1.35 бібліотека cloud-controller-manager впроваджує стратегію узгодження на основі спостереження для контролера маршрутів. Замість того, щоб покладатися на таймер, контролер тепер використовує інформери для спостереження за конкретними подіями вузла, такими як додавання, видалення або відповідні оновлення полів, і запускає синхронізацію маршрутів тільки тоді, коли насправді відбувається зміна.

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

Ця робота була виконана в рамках KEP #5237 під керівництвом SIG Cloud Provider.

Розширені оператори толерантності для розміщення на основі порогових значень

Kubernetes v1.35 впроваджує планування з урахуванням SLA, дозволяючи робочим навантаженням формулювати вимоги до надійності. Ця функція додає оператори числового порівняння до толерантності, дозволяючи подам використовувати або уникати вузлів на основі SLA-орієнтованих позначок, таких як гарантії обслуговування або якість домену збоїв.

Основна перевага полягає в удосконаленні планувальника за допомогою більш точного розміщення. Критичні робочі навантаження можуть вимагати вузлів з вищим SLA, тоді як робочі навантаження з нижчим пріоритетом можуть обирати вузли з нижчим SLA. Це покращує використання та зменшує витрати без шкоди для надійності.

Ця робота була виконана в рамках KEP #5471 під керівництвом SIG Scheduling.

Змінні ресурси контейнера у випадку призупинення Job

Виконання пакетних робочих навантажень часто супроводжується спробами та помилками з обмеженнями ресурсів. Наразі специфікація Job є незмінною, що означає: якщо завдання Job завершується з помилкою Out of Memory (OOM) або через недостатню кількість ресурсів CPU, користувач не може просто налаштувати ресурси; він повинен видалити завдання Job і створити нове, втрачаючи історію виконання та статус.

Kubernetes v1.35 впроваджує можливість оновлення запитів на ресурси та обмежень для Завдань, які перебувають у призупиненому стані. Ця функція, яка вмикається за допомогою функціональної можливості MutablePodResourcesForSuspendedJobs, дозволяє користувачам призупиняти завдання, що завершилося збоєм, змінювати його шаблон Pod з відповідними значеннями ресурсів, а потім поновлювати виконання з виправленою конфігурацією.

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

Ця робота була виконана в рамках KEP #5440 під керівництвом SIG Apps.

Інші важливі зміни

Подальші інновації в динамічному розподілі ресурсів (DRA)

Основна функціональність була переведена в стабільний стан у версії 1.34 з можливістю її відключення. У версії 1.35 вона завжди ввімкнена. Декілька альфа-функцій також були значно вдосконалені і готові до тестування. Ми закликаємо користувачів надавати відгуки про ці можливості, щоб допомогти прокласти шлях для їх переходу в бета-версію в майбутніх релізах.

Розширені запити на ресурси через DRA

Було усунено кілька функціональних прогалин порівняно з розширеними запитами на ресурси через втулки пристроїв, наприклад, оцінка та повторне використання пристроїв в контейнерах ініціалізації.

Позначення та толерантність пристроїв

Новий ефект "None" можна використовувати для повідомлення про проблему без негайного впливу на планування або роботу подів. DeviceTaintRule тепер надає інформацію про стан поточного виселення. Ефект "None" можна використовувати для «пробного запуску» перед фактичним виселенням подів:

Створіть DeviceTaintRule з "effect: None".
Перевірте стан, щоб побачити, скільки подів буде виселено.
Замініть "effect: None" на "effect: NoExecute".

Пристрої, що розділяються на розділи

Пристрої, що належать до одних і тих самих пристроїв, які можна розділити, тепер можна визначати в різних ResourceSlices. Більше інформації можна знайти в офіційній документації.

Споживана ємність, умови привʼязки пристроїв

Було виправлено кілька помилок та/або додано більше тестів. Більше інформації про Споживчу ємність та Умови привʼязки можна знайти в офіційній документації.

Семантика порівнянних версій ресурсів

У Kubernetes v1.35 змінено спосіб, у який клієнти можуть інтерпретувати версії ресурсів.

До версії v1.35 єдиним підтримуваним порівнянням, яке клієнти могли виконувати, була перевірка рівності рядків: якщо дві версії ресурсів були рівними, вони вважалися однаковими. Клієнти також могли надавати версію ресурсу серверу API і просити панель управління виконувати внутрішні порівняння, наприклад, передавати всі події з певної версії ресурсу.

У версії 1.35 усі версії вбудованих ресурсів відповідають новому, більш суворому визначенню: значення є спеціальною формою десяткового числа. А оскільки їх можна порівнювати, клієнти можуть виконувати власні операції для порівняння двох різних версій ресурсів. Наприклад, це означає, що клієнт, який повторно підключається після збою, може виявити, коли він втратив оновлення, на відміну від випадку, коли було оновлення, але тим часом не було втрачених змін.

Ця зміна в семантиці дозволяє реалізувати інші важливі випадки використання, такі як міграція версій сховища, поліпшення продуктивності informers (концепція допоміжного клієнта) та надійність контролера. Усі ці випадки вимагають знання того, чи є одна версія ресурсу новішою за іншу.

Ця робота була виконана в рамках KEP #5504 під керівництвом SIG API Machinery.

Зміна статусу, застарілі та видалені функції у версії 1.35

Переходи до стабільної версії

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

Цей випуск містить загалом 15 вдосконалень, які перейшли до стабільної версії:

Застарілі функції, видалення та оновлення від спільноти

У міру розвитку та вдосконалення Kubernetes деякі функції можуть ставати застарілими, видалятися або замінюватися кращими для поліпшення загального стану проєкту. Докладнішу інформацію про цей процес див. у політиці Kubernetes щодо застарілих та видалених функцій. У Kubernetes v1.35 є кілька функцій, визнаних застарілими.

Виведення з експлуатації Ingress NGINX

Протягом багатьох років контролер Ingress NGINX був популярним вибором для маршрутизації трафіку в кластери Kubernetes. Він був гнучким, широко використовувався і служив стандартною точкою входу для незліченних застосунків.

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

Як наслідок, проєкт Kubernetes оголосив, що Ingress NGINX отримуватиме лише мінімальне обслуговування до березня 2026 року. Після цієї дати він буде заархівований без подальших оновлень. Рекомендований варіант подальших дій — перехід на Gateway API, який пропонує більш сучасний, безпечний і розширюваний стандарт управління трафіком.

Більше інформації ви можете знайти в офіційному дописі в блозі.

Видалення підтримки cgroup v1

Що стосується управління ресурсами на вузлах Linux, Kubernetes історично покладався на cgroups (контрольні групи). Хоча оригінальний cgroup v1 був функціональним, він часто був непослідовним і обмеженим. Ось чому Kubernetes ще в версії v1.25 запровадив підтримку cgroup v2, пропонуючи набагато чистішу, уніфіковану ієрархію та кращу ізоляцію ресурсів.

Оскільки cgroup v2 тепер є сучасним стандартом, Kubernetes готовий відмовитися від підтримки застарілого cgroup v1 у версії v1.35. Це важливе повідомлення для адміністраторів кластерів: якщо ви все ще використовуєте вузли на старих дистрибутивах Linux, які не підтримують cgroup v2, ваш kubelet не запуститься. Щоб уникнути простою, вам потрібно буде перенести ці вузли на системи, де ввімкнено cgroup v2.

Щоб дізнатися більше, прочитайте про cgroup v2; ви також можете стежити за переходом в KEP-5573: Remove cgroup v1 support.

Виведення з експлуатації режиму ipvs в kube-proxy

Кілька років тому Kubernetes застосував режим ipvs у kube-proxy, щоб забезпечити швидше балансування навантаження, ніж стандартний режим iptables. Хоча це забезпечило підвищення продуктивності, синхронізація з мінливими вимогами до мережі створила занадто великий технічний борг і складність.

Через це навантаження на обслуговування Kubernetes v1.35 відмовляється від режиму ipvs. Хоча цей режим залишається доступним у цій версії, kube-proxy тепер видаватиме попередження під час запуску, якщо він налаштований на його використання. Мета полягає в оптимізації кодової бази та зосередженні уваги на сучасних стандартах. Для вузлів Linux слід почати перехід на nftables, який зараз є рекомендованою заміною.

Більше інформації можна знайти в KEP-5495: Deprecate ipvs mode in kube-proxy.

Останній дзвоник для containerd v1.X

Хоча Kubernetes v1.35 все ще підтримує containerd 1.7 та інші випуски LTS, це остання версія з такою підтримкою. Спільнота SIG Node визначила v1.35 як останній випуск, що підтримує серію containerd v1.X.

Це важливе нагадування: перед оновленням до наступної версії Kubernetes ви повинні перейти на containerd 2.0 або новішу версію. Щоб визначити, які вузли потребують уваги, ви можете відстежувати метрику kubelet_cri_losing_support у своєму кластері.

Більше інформації ви можете знайти в офіційному дописі в блозі або в KEP-4033: Discover cgroup driver from CRI.

Покращена стабільність Podʼів під час перезапуску `kubelet`

Раніше перезапуск служби kubelet часто спричиняв тимчасове порушення стану Podʼів. Під час перезапуску kubelet скидав стан контейнерів, через що справні Podʼи позначалися як NotReady і видалялися з балансувальників навантаження, навіть якщо застосунок сам по собі працював належним чином.

Щоб вирішити цю проблему надійності, таку поведінку було виправлено, щоб забезпечити безперебійне обслуговування вузлів. Тепер kubelet правильно відновлює стан поточних контейнерів з середовища виконання під час запуску. Це гарантує, що ваші робочі навантаження залишаються в стані Ready, а трафік продовжує безперебійно надходити під час перезапуску або оновлення kubelet.

Більше інформації ви можете знайти в KEP-4781: Fix inconsistent container ready state after kubelet restart.

Примітки до випуску

Ознайомтеся з повною інформацією про випуск Kubernetes v1.35 у наших примітках до випуску.

Доступність

Kubernetes v1.35 доступний для завантаження на GitHub або на сторінці завантаження Kubernetes.

Щоб розпочати роботу з Kubernetes, ознайомтеся з цими інтерактивними посібниками або запустіть локальні кластери Kubernetes за допомогою minikube. Ви також можете легко встановити v1.35 за допомогою kubeadm.

Команда випуску

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

Ми вшановуємо памʼять Хана Канга, багаторічного учасника та шановного інженера, чия технічна досконалість та заразливий ентузіазм залишили незабутній слід у спільноті Kubernetes. Хан був значною силою в SIG Instrumentation та SIG API Machinery, отримавши нагороду Kubernetes Contributor Award 2021 за свою важливу роботу та постійну відданість стабільності проєкту. Окрім технічного внеску, Хана глибоко поважали за його щирість як наставника та пристрасть до налагодження звʼязків між людьми. Він був відомий тим, що «відкривав двері» для інших, чи то допомагаючи новим учасникам з їхніми першими pull-request, чи то підтримуючи колег з терпінням і добротою. Спадщина Хана живе в інженерах, яких він надихнув, у надійних системах, які він допоміг створити, та в теплій атмосфері співпраці, яку він культивував у хмарній екосистемі.

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

Швидкість проєкту

Проєкт CNCF K8s DevStats обʼєднує низку цікавих даних, повʼязаних зі швидкістю Kubernetes та різних підпроєктів. Сюди входить все, від індивідуальних внесків до кількості компаній, які роблять внески, і це ілюструє глибину та широту зусиль, що докладаються для розвитку цієї екосистеми.

Під час циклу випуску версії 1.35, який тривав 14 тижнів з 15 вересня 2025 року по 17 грудня 2025 року, Kubernetes отримав внески від 85 різних компаній та 419 окремих осіб. У ширшій екосистемі хмарних технологій ця цифра зростає до 281 компанії, що налічує 1769 учасників.

Зверніть увагу, що «внесок» враховується, коли хтось робить коміт, рецензує код, залишає коментар, створює тікет або PR, рецензує PR (включаючи блоги та документацію) або коментує тікети та PR. Якщо ви зацікавлені у співпраці, відвідайте розділ Початок роботи на нашому веб-сайті для учасників.

Джерела цих даних:

Огляд подій

Дізнайтеся про майбутні події, присвячені Kubernetes та хмарним технологіям, зокрема KubeCon + CloudNativeCon, KCD та інші важливі конференції по всьому світу. Будьте в курсі подій та долучайтеся до спільноти Kubernetes!

Лютий 2026 року

KCD — Дні спільноти Kubernetes: Нью-Делі: 21 лютого 2026 року | Нью-Делі, Індія
KCD — Дні спільноти Kubernetes: Гвадалахара: 23 лютого 2026 р. | Гвадалахара, Мексика

Березень 2026

KubeCon + CloudNativeCon Europe 2026: 23–26 березня 2026 | Амстердам, Нідерланди

Травень 2026

KCD — Дні спільноти Kubernetes: Торонто: 13 травня 2026 р. | Торонто, Канада
KCD — Дні спільноти Kubernetes: Гельсінкі: 20 травня 2026 р. | Гельсінкі, Фінляндія

Червень 2026

KubeCon + CloudNativeCon India 2026: 18-19 червня 2026 р. | Мумбаї, Індія
KCD — Дні спільноти Kubernetes: Куала-Лумпур: 27 червня 2026 р. | Куала-Лумпур, Малайзія

Липень 2026 р.

KubeCon + CloudNativeCon Japan 2026: 29–30 липня 2026 р. | Йокогама, Японія

Останні подробиці про подію можна знайти тут.

Вебінар про майбутній реліз

Приєднуйтесь до членів команди Kubernetes v1.35 Release Team у середу, 14 січня 2026 року, о 17:00 (UTC), щоб дізнатися про основні особливості цього релізу. Для отримання додаткової інформації та реєстрації відвідайте сторінку події на сайті CNCF Online Programs.

Приєднуйтесь

Найпростіший спосіб долучитися до Kubernetes — приєднатися до однієї з численних спеціальних груп за інтересами (SIG), яка відповідає вашим інтересам. Хочете поділитися чимось із спільнотою Kubernetes? Поділіться своєю думкою на наших щотижневих зустрічах спільноти та через наведені нижче канали. Дякуємо за ваші постійні відгуки та підтримку.

Слідкуйте за нами у Bluesky @Kubernetesio, щоб бути в курсі останніх новин
Приєднуйтесь до обговорення спільноти у Discuss
Приєднуйтесь до спільноти в Slack
Ставте запитання (або відповідайте на запитання) в Stack Overflow
Поділіться своєю історією про Kubernetes
Дізнайтеся більше про те, що відбувається з Kubernetes, у блозі
Дізнайтеся більше про команду випуску Kubernetes

Попередній огляд Kubernetes v1.35

Wed, 26 Nov 2025 00:00:00 +0000

З наближенням випуску Kubernetes v1.35 проєкт Kubernetes продовжує розвиватися. Функції можуть визнаватись застарілими, видаленими або заміненими для поліпшення загального стану проєкту. У цьому дописі в блозі описано заплановані зміни для випуску v1.35, про які, на думку команди випуску, вам слід знати, щоб забезпечити безперебійну роботу ваших кластерів Kubernetes та бути в курсі останніх розробок. Наведена нижче інформація базується на поточному стані версії v1.35 і може бути змінена до дати остаточного випуску.

Застарівання та видалення у версії Kubernetes v1.35

Підтримка cgroup v1

На вузлах Linux середовища виконання контейнерів зазвичай покладаються на cgroups (скорочення від «control groups», групи контролю). Підтримка використання cgroup v2 є стабільною в Kubernetes з версії v1.25, надаючи альтернативу оригінальній підтримці cgroup v1. Хоча cgroup v1 забезпечувала початковий механізм контролю ресурсів, вона мала відомі невідповідності та обмеження. Додавання підтримки cgroup v2 дозволило використовувати уніфіковану ієрархію контрольних груп, поліпшило ізоляцію ресурсів і стало основою для сучасних функцій, що зробило підтримку застарілої cgroup v1 готовою до видалення. Видалення підтримки cgroup v1 вплине лише на адміністраторів кластерів, які використовують вузли на старих дистрибутивах Linux, що не підтримують cgroup v2; на цих вузлах kubelet не зможе запуститися. Адміністратори повинні перенести свої вузли на системи з увімкненим cgroup v2. Більш детальна інформація про вимоги до сумісності буде доступна в блозі незабаром після випуску версії v1.35.

Щоб дізнатися більше, прочитайте про cgroup v2; ви також можете стежити за роботою з переходу в KEP-5573: Remove cgroup v1 support.

Визнання застарілим режиму ipvs в kube-proxy

Багато версій тому проєкт Kubernetes реалізував режим ipvs в kube-proxy. Він був прийнятий як спосіб забезпечення високоефективного балансування навантаження сервісів, з кращою продуктивністю, ніж наявний режим iptables. Однак підтримка функціональної рівності між ipvs та іншими режимами kube-proxy стала складною через технічну складність та розбіжності у вимогах. Це створило значний технічний борг і зробило бекенд ipvs непрактичним для підтримки поряд з новими мережевими можливостями.

Проєкт Kubernetes має намір відмовитися від режиму kube-proxy ipvs у версії v1.35, щоб оптимізувати кодову базу kube-proxy. Для вузлів Linux рекомендованим режимом kube-proxy вже є nftables.

Більше інформації можна знайти в KEP-5495: Deprecate ipvs mode in kube-proxy.

Kubernetes припиняє підтримку containerd v1.y

Хоча Kubernetes v1.35 все ще підтримує containerd 1.7 та інші LTS-версії containerd, внаслідок автоматичного виявлення драйвера cgroup спільнота Kubernetes SIG Node офіційно погодила остаточний графік підтримки containerd v1.X. Kubernetes v1.35 є останньою версією, яка пропонує цю підтримку (відповідно до EOL containerd 1.7).

Це останнє попередження про те, що якщо ви використовуєте containerd 1.X, ви повинні перейти на 2.0 або пізнішу версію перед оновленням Kubernetes до наступної версії. Ви можете відстежувати метрику kubelet_cri_losing_support, щоб визначити, чи використовують якісь вузли у вашому кластері версію containerd, яка незабаром перестане підтримуватися.

Більше інформації ви можете знайти в офіційному блозі або в KEP-4033: Discover cgroup driver from CRI

Основні вдосконалення Kubernetes v1.35

Наступні вдосконалення є одними з тих, які, ймовірно, будуть включені до версії v1.35. Це не є зобовʼязанням, і зміст версії може бути змінений.

Можливості, оголошені вузлами

Під час планування Podʼів Kubernetes використовує мітки вузлів, позначки taints та толерантності, щоб узгодити вимоги до робочого навантаження з можливостями вузлів. Однак управління сумісністю можливостей стає складним під час оновлення кластера через розбіжність версій між панеллю управління та вузлами. Це може призвести до планування Podʼів на вузлах, які не мають необхідних можливостей, що спричинить збої під час виконання.

Фреймворк node declared features запровадить стандартний механізм для вузлів, щоб вони могли оголошувати свої підтримувані функції в Kubernetes. З увімкненою новою альфа-функцією вузол повідомляє про функції, які він може підтримувати, публікуючи цю інформацію у панелі управління через нове поле .status.declaredFeatures. Потім kube-scheduler, контролери допуску та сторонні компоненти можуть використовувати ці оголошення. Наприклад, ви можете застосувати обмеження планування та перевірки API, гарантуючи, що Podʼи працюють тільки на сумісних вузлах.

Цей підхід зменшує ручне маркування вузлів, покращує точність планування та запобігає розміщенню несумісних podʼів. Він також інтегрується з Cluster Autoscaler для обґрунтованих рішень щодо масштабування. Декларації функцій є тимчасовими та повʼязані з функціональними можливостями Kubernetes, що забезпечує безпечне впровадження та очищення.

Орієнтуючись на альфа-версію в v1.35, node declared features має на меті вирішити проблеми планування версій, зробивши можливості вузлів явними, підвищивши надійність і стабільність кластера в гетерогенних версійних середовищах.

Щоб дізнатися більше про це до опублікування офіційної документації, ви можете прочитати KEP-5328.

Оновлення ресурсів Podʼів на місці

Kubernetes переводить оновлення ресурсів Podʼів на місці в статус загальної доступності (GA). Ця функція дозволяє користувачам налаштовувати ресурси cpu та memory без перезапуску Podʼів або Containerʼів. Раніше для таких модифікацій було потрібно перестворювати Podʼи, що могло порушити робочі навантаження, особливо для застосунків зі збереженням стану або пакетних застосунків. Попередні версії Kubernetes вже дозволяли змінювати налаштування ресурсів інфраструктури (запити та обмеження) для наявних Podʼів. Це забезпечує більш плавне вертикальне масштабування, підвищує ефективність, а також може спростити розробку рішень.

Також було вдосконалено інтерфейс Container Runtime Interface (CRI), розширивши API UpdateContainerResources для Windows і майбутніх середовищ виконання, а також дозволивши ContainerStatus повідомляти про конфігурації ресурсів у реальному часі. У сукупності ці зміни роблять масштабування в Kubernetes швидшим, гнучкішим і безперебійним. Ця функція була представлена в альфа-версії v1.27, перейшла в бета-версію v1.33 і планується до випуску в стабільній версії v1.35.

Більше інформації ви можете знайти в KEP-1287: In-place Update of Pod Resources

Сертифікати Podʼів

Під час виконання мікросервісів Podʼи часто потребують надійної криптографічної ідентифікації для взаємної автентифікації за допомогою mutual TLS (mTLS). Хоча Kubernetes надає токени Service Account, вони призначені для автентифікації на сервері API, а не для загальної ідентифікації робочих навантажень.

До цього вдосконалення оператори мали покладатися на складні зовнішні проєкти, такі як SPIFFE/SPIRE або cert-manager, для надання та ротації сертифікатів для своїх робочих навантажень. Але що якби ви могли видавати унікальний сертифікат з коротким терміном дії для своїх Podʼів нативно і автоматично? KEP-4317 призначений для забезпечення такої нативної ідентифікації робочих навантажень. Він відкриває різні можливості для захисту комунікації між Podʼами, дозволяючи kubelet запитувати і монтувати сертифікати для Podʼів через спроєцьований том.

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

Більше інформації ви можете знайти в KEP-4317: Pod Certificates

Числові значення для taints

Kubernetes вдосконалює позначки taint та толерантності шляхом додавання числових операторів порівняння, таких як Gt (більше ніж) та Lt (менше ніж).

Раніше толерантності підтримували лише точні (Equal) або збіги існування (Exists), що не підходило для числових властивостей, таких як SLA надійності.

Завдяки цій зміні Pod може використовувати толерантність для «підключення» до вузлів, які відповідають певному числовому порогу. Наприклад, Pod може вимагати Node з значенням SLA taint більше 950 (operator: Gt, value: "950").

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

Більше інформації ви можете знайти в KEP-5471: Enable SLA-based Scheduling

Простори імен користувачів

Під час запуску Podʼів ви можете використовувати securityContext для скасування привілеїв, але контейнери всередині podʼів часто все одно працюють як root (UID 0). Ця простота створює значну проблему, оскільки UID 0 контейнера безпосередньо відповідає користувачеві root хоста.

До цього вдосконалення вразливість контейнера могла надати зловмиснику повний root-доступ до вузла. А що, якби ви могли динамічно перепризначити root-користувача контейнера на безпечного користувача без привілеїв на хості? KEP-127 спеціально дозволяє таку вбудовану підтримку для просторів імен користувачів Linux. Це відкриває різні можливості для безпеки podʼів, ізолюючи ідентифікатори користувачів/груп контейнера та хоста. Це дозволяє процесу мати привілеї root (UID 0) у своєму просторі імен, працюючи як непривілейований UID з високим номером на хості.

Випущена в альфа-версії v1.25 і бета-версії v1.30, ця функція продовжує розвиватися в бета-версії, прокладаючи шлях для справді "rootless" контейнерів, які різко зменшують площу атаки для цілого класу вразливостей безпеки.

Більше інформації ви можете знайти в KEP-127: User Namespaces

Підтримка монтування образів OCI як томів

Під час провізування Podʼів часто потрібно обʼєднувати дані, бінарні файли або файли конфігурації для контейнерів. До цього вдосконалення такі дані часто включали безпосередньо в основний образ контейнера або вимагали спеціального контейнера init для завантаження та розпакування файлів у emptyDir. Звичайно, ви все ще можете використовувати будь-який з цих підходів.

Але що, якби ви могли заповнити том безпосередньо з артефакту, що містить тільки дані, в реєстрі OCI, так само, як ви завантажуєте образ контейнера? У Kubernetes v1.31 додано підтримку типу тому image, що дозволяє Podʼам завантажувати та розпаковувати артефакти образів контейнерів OCI в том декларативно.

Це дозволяє безперешкодно розподіляти дані, бінарні файли або ML-моделі за допомогою стандартних інструментів реєстру, повністю відокремлюючи дані від образу контейнера та усуваючи необхідність у складних контейнерах ініціалізації або скриптах запуску. Цей тип тому перебуває в бета-версії з v1.33 і, ймовірно, буде стандартно ввімкнений у v1.35.

Ви можете спробувати бета-версію томів image або дізнатися більше про плани з KEP-4639: OCI Volume Source.

Хочете дізнатися більше?

Нові функції та застарівання функції також оголошуються в примітках до випуску Kubernetes. Ми офіційно оголосимо про нововведення в Kubernetes v1.35 у рамках CHANGELOG для цього випуску.

Випуск Kubernetes v1.35 заплановано на 17 грудня 2025 року. Слідкуйте за оновленнями!

Ви також можете переглянути оголошення про зміни в примітках до випуску для:

Долучайтеся до спільноти

Найпростіший спосіб долучитися до Kubernetes — приєднатися до однієї з численних спеціальних груп за інтересами (SIG), яка відповідає вашим інтересам. Хочете поділитися чимось із спільнотою Kubernetes? Висловіть свою думку на нашому щотижневому зібранні спільноти та у наведених нижче каналах. Дякуємо за ваші відгуки та підтримку.

Слідкуйте за нами у Bluesky @kubernetes.io, щоб отримувати останні оновлення
Приєднуйтесь до обговорення на Discuss
Приєднуйтесь до спільноти в Slack
Публікуйте питання (або відповідайте на питання) на Server Fault або Stack Overflow
Поділіться своєю історією про Kubernetes
Дізнайтеся більше про те, що відбувається в Kubernetes, у блозі
Дізнайтеся більше про команду випуску Kubernetes

Закінчення підтримки Ingress NGINX: що потрібно знати

Tue, 11 Nov 2025 10:30:00 -0800

Для забезпечення пріоритетності безпеки та захисту екосистеми, Kubernetes SIG Network та Комітет з реагування на загрози безпеки оголошують про майбутнє завершення підтримки Ingress NGINX. Підтримка буде продовжуватися до березня 2026 року. Після цього не буде нових випусків, виправлень помилок та оновлень для усунення будь-яких виявлених вразливостей безпеки. Наявні розгортання Ingress NGINX продовжуватимуть функціонувати, а інсталяційні артефакти залишатимуться доступними.

Ми рекомендуємо перейти на одну з багатьох альтернатив. Розгляньте можливість переходу на Gateway API, сучасну заміну Ingress. Якщо ви мусите продовжувати використовувати Ingress, багато альтернативних контролерів Ingress перелічено в документації Kubernetes. Далі ви знайдете додаткову інформацію про історію та поточний стан Ingress NGINX, а також про наступні кроки.

Про Ingress NGINX

Ingress — це оригінальний зручний спосіб перенаправлення мережевого трафіку на робочі навантаження, що виконуються в Kubernetes. (Gateway API — це новіший спосіб досягнення багатьох тих самих цілей.) Щоб Ingress працював у вашому кластері, повинен бути запущений Ingress controller. Існує багато варіантів Ingress controller, які відповідають потребам різних користувачів і випадків використання. Деякі з них призначені для конкретних хмарних провайдерів, а інші мають більш загальне застосування.

Ingress NGINX був контролером Ingress, розробленим на початку історії проєкту Kubernetes як приклад реалізації API. Він став дуже популярним завдяки своїй надзвичайній гнучкості, широкому набору функцій та незалежності від будь-якого конкретного постачальника хмарних послуг або інфраструктури. З тих пір у рамках проєкту Kubernetes спільнотами та постачальниками хмарних рішень було створено багато інших контролерів Ingress. Ingress NGINX залишається одним із найпопулярніших, його використовують у багатьох хостингових платформах Kubernetes та незліченних кластерах незалежних користувачів.

Історія та виклики

Широта та гнучкість Ingress NGINX спричинили проблеми з технічним обслуговуванням. Зміни в очікуваннях щодо хмарного програмного забезпечення також додали складнощів. Те, що колись вважалося корисними опціями, іноді почало розглядатися як серйозні недоліки безпеки, наприклад, можливість додавати довільні директиви конфігурації NGINX за допомогою анотацій «snippets». Вчорашня гнучкість стала сьогоднішнім непереборним технічним боргом.

Незважаючи на популярність проєкту серед користувачів, Ingress NGINX завжди мав проблеми з недостатнім або ледь достатнім рівнем технічного обслуговування. Протягом багатьох років над проєктом працювали лише одна або дві особи, які займалися розробкою у вільний час, після роботи та у вихідні. Минулого року адміністратори Ingress NGINX оголосили про свої плани припинити роботу над Ingress NGINX і розробити заміну контролера разом із спільнотою Gateway API. На жаль, навіть це оголошення не викликало додаткового інтересу до допомоги в підтримці Ingress NGINX або розробці InGate на заміну. (Розробка InGate ніколи не просунулася настільки, щоб створити зрілу заміну; її також буде припинено.)

Поточний стан та наступні кроки

Наразі Ingress NGINX отримує максимальну підтримку. SIG Network та Комітет з реагування на загрози безпеці вичерпали всі можливості для пошуку додаткової підтримки, щоб забезпечити стабільну роботу Ingress NGINX. З метою забезпечення безпеки користувачів ми змушені припинити роботу над проєктом.

У березні 2026 року технічне обслуговування Ingress NGINX буде припинено, а проєкт буде визнано застарілим. Після цього не буде нових випусків, виправлень помилок та оновлень для усунення будь-яких виявлених вразливостей безпеки. Репозиторії GitHub будуть переведені в режим «тільки для читання» і залишаться доступними для ознайомлення.

Наявні розгортання Ingress NGINX не будуть порушені. Артефакти проєкту, такі як чарти Helm та образи контейнерів, залишаться доступними.

У більшості випадків ви можете перевірити, чи використовуєте ви Ingress NGINX, скориставшись командою kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx з правами адміністратора кластера.

Ми хотіли б подякувати розробникам Ingress NGINX за їхню роботу над створенням та підтримкою цього проєкту — їхня відданість справі залишається вражаючою. Цей контролер Ingress обробив мільярди запитів у дата-центрах та домашніх лабораторіях по всьому світу. Багато в чому Kubernetes не був би тим, чим є зараз, без Ingress NGINX, і ми вдячні за стільки років неймовірних зусиль.

SIG Network та Комітет з реагування на загрози безпеки рекомендують усім користувачам Ingress NGINX негайно розпочати міграцію на Gateway API або інший контролер Ingress. Багато варіантів перелічено в документації Kubernetes: Gateway API, Ingress. Додаткові варіанти можуть бути доступні у постачальників, з якими ви працюєте.

Gateway API 1.4: Нові можливості

Thu, 06 Nov 2025 09:00:00 -0800

Готові до революції у сфері мережевих технологій Kubernetes? Спільнота Kubernetes SIG Network представила загальнодоступну версію Gateway API (v1.4.0)! Випущена 6 жовтня 2025 року версія 1.4.0 зміцнює позиції сучасних, динамічних і розширюваних мережевих технологій у Kubernetes.

Gateway API v1.4.0 приносить три нові можливості до Стандартного каналу (GA-версія Gateway API):

BackendTLSPolicy для TLS між шлюзами та бекендами
supportedFeatures у статусі GatewayClass
Іменовані правила для маршрутів

та вводить три нові експериментальні можливості:

Ресурс Mesh для конфігурації сервісної мережі
Default gateways для спрощення конфігурації
Фільтр externalAuth для HTTPRoute

Перехід до Стандартного каналу

Backend TLS policy

Під проводом: Candace Holman, Norwin Schnyder, Katarzyna Łach

GEP-1897: BackendTLSPolicy.

BackendTLSPolicy — це новий тип Gateway API для визначення конфігурації TLS зʼєднання між шлюзом і подами бекенду. До впровадження BackendTLSPolicy не існувало API-специфікації, яка б дозволяла шифрувати трафік на шляху від шлюзу до бекенду.

Конфігурація BackendTLSPolicy validation вимагає імені хоста. Цей hostname має два призначення. Він використовується як заголовок SNI під час підключення до бекенду, а для автентифікації сертифікат, представлений бекендом, повинен відповідати цьому імені хоста, якщо subjectAltNames не вказано явно.

Якщо subjectAltNames (SAN) вказано, hostname використовується тільки для SNI, а автентифікація виконується на основі SAN. Якщо в цьому випадку все одно потрібно виконати автентифікацію на основі значення імені хоста, його НЕОБХІДНО додати до списку subjectAltNames.

Конфігурація BackendTLSPolicy validation також вимагає або caCertificateRefs, або wellKnownCACertificates. caCertificateRefs посилається на один або декілька (до 8) пакунків сертифікатів TLS, закодованих у форматі PEM. Якщо немає конкретних сертифікатів для використання, то залежно від вашої реалізації ви можете використовувати wellKnownCACertificates, встановлений у значення "System", щоб повідомити шлюз про необхідність використання набору довірених сертифікатів CA, характерних для конкретної реалізації.

У цьому прикладі BackendTLSPolicy налаштований на використання сертифікатів, визначених у ConfigMap auth-cert, для підключення до зашифрованого TLS-зʼєднання, де поди, що підтримують сервіс автентифікації, повинні надавати дійсний сертифікат для auth.example.com. Він використовує subjectAltNames з типом Hostname, але ви також можете використовувати тип URI.

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-auth
spec:
  targetRefs:
  - kind: Service
    name: auth
    group: ""
    sectionName: "https"
  validation:
    caCertificateRefs:
    - group: "" # основна група API
      kind: ConfigMap
      name: auth-cert
    subjectAltNames:
    - type: "Hostname"
      hostname: "auth.example.com"

У цьому прикладі BackendTLSPolicy налаштований на використання системних сертифікатів для підключення до зашифрованого TLS бекенду, де Pods, що обслуговують Service dev, повинні надавати дійсний сертифікат для dev.example.com.

apiVersion: gateway.networking.k8s.io/v1
kind: BackendTLSPolicy
metadata:
  name: tls-upstream-dev
spec:
  targetRefs:
  - kind: Service
    name: dev
    group: ""
    sectionName: "btls"
  validation:
    wellKnownCACertificates: "System"
    hostname: dev.example.com

Більш детальну інформацію про конфігурацію TLS в Gateway API можна знайти в статті Gateway API - TLS Configuration.

Status information about the features that an implementation supports

Під проводом: Lior Lieberman, Beka Modebadze

GEP-2162: Supported features in GatewayClass Status.

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

Назва цієї функції для тестів на відповідність (та звітування про статус GatewayClass) — SupportedFeatures. Реалізації повинні заповнити поле supportedFeatures у .status GatewayClass до прийняття GatewayClass або в рамках тієї ж операції.

Ось приклад supportedFeatures, опублікованого в .status GatewayClass:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
...
status:
  conditions:
  - lastTransitionTime: "2022-11-16T10:33:06Z"
    message: Handled by Foo controller
    observedGeneration: 1
    reason: Accepted
    status: "True"
    type: Accepted
  supportedFeatures:
    - HTTPRoute
    - HTTPRouteHostRewrite
    - HTTPRoutePortRedirect
    - HTTPRouteQueryParamMatching

Перехід SupportedFeatures до Standard допоміг поліпшити процес тестування відповідності для Gateway API. Набір тестів на відповідність тепер автоматично виконуватиме тести на основі функцій, визначених у статусі GatewayClass. Це створює міцний, перевірюваний звʼязок між заявленими можливостями реалізації та результатами тестування, що полегшує для розробників виконання правильних тестів на відповідність, а для користувачів — довіру до звітів про відповідність.

Це означає, що коли поле SupportedFeatures заповнюється в статусі GatewayClass, не буде потреби в додаткових прапорцях тестів на відповідність, таких як –suported-features, або –exempt, або –all-features. Важливо зазначити, що функції Mesh є винятком із цього правила і можуть бути перевірені на відповідність за допомогою Conformance Profiles або шляхом ручного введення будь-якої комбінації прапорців, повʼязаних з функціями, доки спеціальний ресурс не вийде з експериментального каналу.

Іменовані правила для Routes

GEP-995: Adding a new name field to all xRouteRule types (HTTPRouteRule, GRPCRouteRule, etc.).

Під проводом: Guilherme Cassolato

Це вдосконалення дозволяє чітко ідентифікувати правила маршрутизації та посилатися на них у всій екосистемі Gateway API. Ось деякі з основних випадків використання:

Статус: можливість посилатися на конкретні правила безпосередньо за назвою.
Спостережуваність: спрощення ідентифікації окремих правил у журналах, трейсах та метриках.
Політики: Дозволяє політикам (GEP-713) орієнтуватися на конкретні правила маршрутизації через поле sectionName у їх targetRef[s].
Інструменти: спрощення фільтрування та посилання на правила маршрутизації в таких інструментах, як gwctl, kubectl, а також в універсальних утилітах, таких як jq та yq.
Внутрішнє зіставлення конфігурацій: спрощення генерації внутрішніх конфігурацій, які посилаються на правила маршрутизації за іменем у реалізаціях шлюзів і мереж.

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

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

Нарешті, майте на увазі, що [формат імені](https://gateway-api.sigs.k8s.io/geps/gep-995/? h=995#format) перевіряється, а інші поля (такі як sectionName) можуть накладати додаткові непрямі обмеження.

Зміни в експериментальному каналі

Увімкнення зовнішньої автентифікації для HTTPRoute

Надання Gateway API можливості забезпечувати автентифікацію, а можливо, і авторизацію на рівні Gateway або HTTPRoute є дуже запитуваною функцією протягом тривалого часу. (Див. проблему GEP-1494 для отримання додаткової інформації.)

Цей реліз Gateway API додає експериментальний фільтр у HTTPRoute, який вказує реалізації Gateway API викликати зовнішній сервіс для автентифікації (а за бажанням, і авторизації) запитів.

Цей фільтр базується на Envoy ext_authz API і дозволяє спілкуватися зі службою Auth, яка використовує протокол gRPC або HTTP.

Обидва методи дозволяють налаштувати, які заголовки пересилати до служби Auth, причому протокол HTTP дозволяє передавати додаткову інформацію, таку як префікс шляху.

Приклад HTTP може виглядати так (зверніть увагу, що для цього прикладу потрібно встановити експериментальний канал та реалізацію, яка підтримує зовнішню автентифікацію, щоб насправді зрозуміти конфігурацію):

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: require-auth
  namespace: default
spec:
  parentRefs:
    - name: your-gateway-here
  rules:
    - matches:
      - path:
          type: Prefix
          value: /admin
      filters:
        - type: ExternalAuth
          externalAuth:
            protocol: HTTP
            backendRef:
              name: auth-service
            http:
              # Ці заголовки завжди надсилаються для протоколу HTTP,
              # але включені сюди для наочності.
              allowedHeaders:
                - Host
                - Method
                - Path
                - Content-Length
                - Authorization
      backendRefs:
        - name: admin-backend
          port: 8080

Це дозволяє сервісу Auth на сервері використовувати надані заголовки для прийняття рішення про автентифікацію запиту.

Коли запит дозволено, зовнішня служба Auth відповість кодом HTTP 200 і, за бажанням, додатковими заголовками, які будуть включені в запит, що пересилається на сервер. Коли запит відхилено, служба Auth відповість кодом HTTP 403.

Оскільки заголовок Authorization використовується в багатьох методах автентифікації, цей метод можна використовувати для Basic, Oauth, JWT та інших поширених методів автентифікації та авторизації.

Ресурси Mesh

Під проводом: Flynn

GEP-3949: Mesh-wide configuration and supported features

Gateway API v1.4.0 представляє новий експериментальний ресурс Mesh, який надає можливість налаштовувати параметри для всієї мережі та виявляти функції, що підтримуються певною реалізацією мережі. Цей ресурс аналогічний ресурсу Gateway і спочатку буде використовуватися переважно для тестування відповідності, а в майбутньому планується розширити його використання на шлюзи поза кластером.

Ресурс Mesh є кластерним і, як експериментальна функція, має назву XMesh і знаходиться в групі API gateway.networking.x-k8s.io. Ключовим полем є controllerName, яке визначає реалізацію mesh, відповідальну за ресурс. Строка status ресурсу вказує, чи прийняла його реалізація mesh, і перелічує функції, які підтримує mesh.

Однією з цілей цього GEP є уникнення ускладнення для користувачів впровадження mesh. Для спрощення впровадження очікується, що реалізації mesh створюватимуть стандартний ресурс Mesh під час запуску, якщо такий з відповідним controllerName ще не існує. Це усуває необхідність ручного створення ресурсу для початку використання mesh.

Новий тип XMesh API в групі API gateway.networking.x-k8s.io/v1alpha1 забезпечує центральний пункт для конфігурації mesh і виявлення функцій (джерело).

Мінімальний обʼєкт XMesh вказує controllerName:

apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XMesh
metadata:
  name: one-mesh-to-mesh-them-all
spec:
  controllerName: one-mesh.example.com/one-mesh

Реалізація mesh заповнює поле статусу, щоб підтвердити, що вона прийняла ресурс, і показує список підтримуваних функцій (джерело):

status:
  conditions:
    - type: Accepted
      status: "True"
      reason: Accepted
  supportedFeatures:
    - name: MeshHTTPRoute
    - name: OffClusterGateway

Впровадження стандартних Gateways

Під проводом: Flynn

GEP-3793: Allowing Gateways to program some routes by default.

Розробники застосунків часто зазначали, що необхідно явно вказувати батьківський шлюз для кожного маршруту північ-південь. Хоча така явність запобігає двозначності, вона створює додаткові труднощі, особливо для розробників, які просто хочуть відкрити свій застосунок для зовнішнього світу, не турбуючись про схему іменування базової інфраструктури. Щоб вирішити цю проблему, ми запровадили поняття Default Gateways.

Для розробників застосунків: просто «використовуйте стандартні налаштування»

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

Для цього потрібно встановити нове поле useDefaultGateways у spec вашого маршруту.

Ось простий HTTPRoute, який використовує стандартний шлюз:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
spec:
  useDefaultGateways: All
  rules:
  - backendRefs:
    - name: my-service
      port: 80

Ось і все! Більше не потрібно шукати правильну назву шлюзу для вашого середовища. Ваш маршрут тепер є «стандартним маршрутом».

Для операторів кластерів: ви все ще контролюєте ситуацію

Ця функція не забирає контроль у операторів кластерів ("Chihiro"¹). Насправді, вони мають явний контроль над тим, які шлюзи можуть діяти як стандартні. Шлюз прийме ці стандартні маршрути лише в тому випадку, якщо він налаштований на це.

Ви також можете використовувати ValidatingAdmissionPolicy, щоб вимагати або навіть забороняти маршрутам покладатися на стандартний Gateway.

Як оператор кластера, ви можете призначити шлюз як стандартний, встановивши (нове) поле .spec.defaultScope:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-default-gateway
  namespace: default
spec:
  defaultScope: All
  # ... інша конфігурація шлюзу

Оператори можуть обрати не використовувати стандартні шлюзи або навіть використовувати декілька.

Як це працює та основні деталі

Щоб підтримувати чистий, дружній до GitOps робочий процес, стандартний шлюз не змінює spec.parentRefs вашого маршруту. Натомість, звʼязок відображається у полі status маршруту. Ви завжди можете перевірити розділ status.parents вашого маршруту, щоб точно побачити, який шлюз або шлюзи його прийняли. Це зберігає ваш початковий намір і уникає конфліктів з інструментами CD.
Дизайн явно підтримує наявність кількох шлюзів, призначених як стандартні в межах кластера. Коли це відбувається, стандартний маршрут буде привʼязаний до всіх з них. Це дозволяє операторам кластерів виконувати міграції без простоїв і тестування нових стандартних шлюзів.
Ви можете створити один маршрут, який обробляє як північ-південь (трафік, що входить або виходить з кластера, через стандартний шлюз), так і схід-захід/mesh-трафік (трафік між сервісами в межах кластера), явно посилаючись на сервіс в parentRefs.

Стандартні шлюзи представляють собою значний крок вперед у спрощенні та інтуїтивності Gateway API для повсякденних випадків використання, поєднуючи гнучкість, необхідну операторам, і простоту, бажану розробниками.

Налаштування перевірки сертифіката клієнта

Під проводом: Arko Dasgupta, Katarzyna Łach

GEP-91: Address connection coalescing security issue

Цей випуск містить оновлення для налаштування перевірки клієнтських сертифікатів, що усуває критичну вразливість безпеки, повʼязану з повторним використанням зʼєднання. Обʼєднання HTTP-зʼєднань — це оптимізація веб-продуктивності, яка дозволяє клієнту повторно використовувати наявне TLS-зʼєднання для запитів до різних доменів. Хоча це зменшує накладні витрати на встановлення нових зʼєднань, воно створює ризик для безпеки в контексті шлюзів API. Можливість повторного використання одного TLS-зʼєднання для декількох прослуховувачів вимагає впровадження спільної конфігурації клієнтських сертифікатів, щоб уникнути несанкціонованого доступу.

Чому mTLS на основі SNI не є рішенням

Можна було б подумати, що використання Server Name Indication (SNI) для розрізнення між прослуховувачами вирішить цю проблему. Однак TLS SNI не є надійним механізмом для забезпечення політик безпеки в сценарії обʼєднання зʼєднань. Клієнт може використовувати одне TLS-зʼєднання для кількох зʼєднань з партнерами, якщо вони всі покриті одним і тим же сертифікатом. Це означає, що клієнт може встановити зʼєднання, вказавши одну ідентичність партнера (використовуючи SNI), а потім повторно використовувати це зʼєднання для доступу до іншого віртуального хоста, який прослуховує на тій же IP-адресі та порту. Це повторне використання, яке контролюється евристикою з боку клієнта, може обійти політики взаємного TLS, які були специфічні для конфігурації другого прослуховувача.

Ось приклад, щоб допомогти пояснити це:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: wildcard-tls-gateway
spec:
  gatewayClassName: example
  listeners:
  - name: foo-https
    protocol: HTTPS
    port: 443
    hostname: foo.example.com
    tls:
      certificateRefs:
      - group: "" # основна група API
        kind: Secret
        name: foo-example-com-cert  # SAN: foo.example.com
  - name: wildcard-https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      certificateRefs:
      - group: "" # основна група API
        kind: Secret
        name: wildcard-example-com-cert # SAN: *.example.com

Я налаштував шлюз із двома прослуховувачами, обидва з яких мають імена хостів, що перетинаються. Моя мета полягає в тому, щоб прослуховувач foo-http був доступний тільки для клієнтів, які мають сертифікат foo-example-com-cert. На відміну від цього, прослуховувач wildcard-https повинен дозволяти доступ ширшій аудиторії, яка використовує будь-який сертифікат, дійсний для домену *.example.com.

Розглянемо сценарій, в якому клієнт спочатку підключається до foo.example.com. Сервер запитує і успішно перевіряє сертифікат foo-example-com-cert, встановлюючи зʼєднання. Згодом той самий клієнт бажає отримати доступ до інших сайтів у цьому домені, таких як bar.example.com, який обробляється слухачем wildcard-https. Завдяки повторному використанню зʼєднання клієнти можуть отримати доступ до бекендів wildcard-https без додаткового TLS-рукостискання на наявному зʼєднанні. Цей процес працює як очікується.

Однак критична вразливість безпеки виникає, коли порядок доступу змінюється на протилежний. Якщо клієнт спочатку підключається до bar.example.com і надає дійсний сертифікат bar.example.com, зʼєднання встановлюється успішно. Якщо потім цей клієнт намагається отримати доступ до foo.example.com, сертифікат клієнта наявного зʼєднання не буде повторно перевірено. Це дозволяє клієнту обійти конкретну вимогу щодо сертифіката для бекенду foo, що призводить до серйозного порушення безпеки.

Рішення: конфігурація TLS для кожного порту

Оновлений API шлюзу отримує поле tls у .spec шлюзу, яке дозволяє визначити конфігурацію перевірки сертифіката клієнта за замовчуванням для всіх прослуховувачів, а потім, якщо потрібно, переоприділити її для кожного порту. Це забезпечує гнучкий і потужний спосіб управління вашими політиками TLS.

Ось погляд на оновлені визначення API (показані як вихідний код Go):

// GatewaySpec визначає бажаний стан Gateway.
type GatewaySpec struct {
    ...
    // GatewayTLSConfig визначає конфігурацію TLS для шлюзу.
    TLS *GatewayTLSConfig `json:"tls,omitempty"`
}

// GatewayTLSConfig визначає конфігурацію TLS для шлюзу.
type GatewayTLSConfig struct {
    // Default визначає стандартну конфігурацію перевірки сертифіката клієнта
    Default TLSConfig `json:"default"`

    // PerPort визначає конфігурацію TLS, призначену для кожного порту.
    PerPort []TLSPortConfig `json:"perPort,omitempty"`
}

// TLSPortConfig описує конфігурацію TLS для конкретного порту.
type TLSPortConfig struct {
    // Port вказує номер порту, до якого буде застосовано конфігурацію TLS.
    Port PortNumber `json:"port"`

    // TLS зберігає конфігурацію, яка буде застосована до всіх прослуховувачів, що обробляють
    // HTTPS-трафік і відповідають заданому порту.
    TLS TLSConfig `json:"tls"`
}

Істотні зміни

Standard GRPCRoute - поле `.spec` обовʼязкове (технічний аспект)

Переведення GRPCRoute до статусу Standard вносить незначну, але технічно важливу зміну щодо наявності поля верхнього рівня .spec. В рамках досягнення статусу Standard, Gateway API посилив перевірку схеми OpenAPI в GRPCRoute CustomResourceDefinition (CRD), щоб чітко забезпечити необхідність поля spec для всіх ресурсів GRPCRoute. Ця зміна забезпечує більш суворе дотримання стандартів обʼєктів Kubernetes та підвищує стабільність і передбачуваність ресурсу. Хоча дуже малоймовірно, що користувачі намагалися визначити GRPCRoute без будь-яких специфікацій, будь-які наявні автоматизації або маніфести, які могли покладатися на вільну інтерпретацію, що дозволяла повну відсутність поля spec, тепер не пройдуть перевірку і повинні бути оновлені, щоб включити поле .spec, навіть якщо воно порожнє.

Експериментальна підтримка CORS в HTTPRoute — кардинальна зміна для поля `allowCredentials`

В рамках підпроєкту Gateway API було внесено істотні зміни до експериментальної підтримки CORS в HTTPRoute, що стосуються поля allowCredentials в політиці CORS. Визначення цього поля було приведене у повну відповідність до специфікації CORS, яка вимагає, щоб відповідний заголовок Access-Control-Allow-Credentials мав булеве значення. Раніше реалізація могла бути надто дозвільною, потенційно приймаючи нестандартні або рядкові представлення, такі як true, через послаблення перевірки схеми. Користувачі, які налаштовували правила CORS, тепер повинні переглянути свої маніфести та переконатися, що значення allowCredentials суворо відповідає новій, більш обмежувальній схемі. Будь-які наявні визначення HTTPRoute, які не відповідають цій більш суворій перевірці, тепер будуть відхилені сервером API, що вимагатиме оновлення конфігурації для збереження функціональності.

Поліпшення досвіду розробки та використання

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

Додано Kube API Linter до конвеєрів CI/CD, що зменшує навантаження на рецензентів API, а також зменшує кількість типових помилок.
Покращено час виконання тестів CRD за допомогою envtest.

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

Тепер у довідці API чітко вказано, коли поле є experimental.
Навігаційна панель GEP (GatewayAPI Enhancement Proposal) генерується автоматично, показуючи реальний стан вдосконалень.

Спробуйте

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

Щоб спробувати API, дотримуйтесь Посібника для початківців.

На момент написання цієї статті сім реалізацій вже відповідають Gateway API v1.4.0. В алфавітному порядку:

Долучайтеся

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

Ознайомтеся з посібниками для користувачів, щоб дізнатися, які випадки використання можна вирішити.
Спробуйте один з наявних контролерів Gateway.
Або долучайтеся до нашої спільноти та допоможіть нам разом створити майбутнє Gateway API!

Учасники проекту хотіли б подякувати усім, хто долучився до Gateway API, чи то через коміти в репозиторії, обговорення, ідеї чи загальну підтримку. Ми ніколи не змогли б досягти такого прогресу без підтримки цієї відданої та активної спільноти.

Gateway API v1.3.0: Advancements in Request Mirroring, CORS, Gateway Merging, and Retry Budgets (червень 2025)
Gateway API v1.2: WebSockets, Timeouts, Retries, and More (листопад 2024)
Gateway API v1.1: Service mesh, GRPCRoute, and a whole lot more (травень 2024)
New Experimental Features in Gateway API v1.0 (листопад 2023)
Gateway API v1.0: GA Release (жовтень 2023)

Чіхіро — японське імʼя, яке має кілька значень залежно від використовуваного кандзі, найчастіше перекладається як «тисяча питань» або «тисяча ліктів». ↩︎

7 типових помилок Kubernetes (і як я навчився їх уникати)

Mon, 20 Oct 2025 08:30:00 -0700

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

1. Оминання запитів на ресурси та обмежень

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

Контекст: У Kubernetes запити та обмеження ресурсів є критично важливими для ефективного управління кластерами. Запити ресурсів гарантують, що планувальник зарезервує відповідну кількість CPU та памʼяті для кожного пода, гарантуючи, що він має необхідні ресурси для роботи. Обмеження ресурсів обмежують кількість CPU та памʼяті, яку може використовувати под, запобігаючи тому, щоб жоден окремий под не споживав надмірні ресурси та потенційно не позбавляв інші поди ресурсів. Коли запити та обмеження ресурсів не встановлені:

Нестача ресурсів: Поди можуть отримувати недостатньо ресурсів, що призводить до зниження продуктивності або збоїв. Це відбувається тому, що Kubernetes планує поди на основі цих запитів. Без них планувальник може розмістити занадто багато подів на одному вузлі, що призводить до конкуренції за ресурси та вузьких місць у продуктивності.
Привласнення ресурсів: З іншого боку, без обмежень под може споживати більше, ніж йому належить, впливаючи на продуктивність і стабільність інших подів на тому ж вузлі. Це може призвести до таких проблем, як виселення або знищення інших подів за допомогою Out-Of-Memory (OOM) killer через брак доступної памʼяті.

Як уникнути цього:

Почніть з помірних requests (наприклад, 100m CPU, 128Mi памʼяті) і подивіться, як ваш застосунок поводиться.
Моніторте реальне використання та уточнюйте свої значення; HorizontalPodAutoscaler може допомогти автоматизувати масштабування на основі метрик.
Слідкуйте за kubectl top pods або вашим інструментом логування/моніторингу, щоб підтвердити, що ви не перевищуєте або недопостачаєте ресурси.

Перевірка життям: На початку я ніколи не думав про обмеження памʼяті. Здавалося, що все гаразд на моєму локальному кластері. Потім, у більшому середовищі, Pods отримали OOMKilled зліва і справа. Урок засвоєно. Для отримання детальних інструкцій щодо налаштування запитів і обмежень ресурсів для ваших контейнерів, будь ласка, зверніться до Призначення ресурсів памʼяті для контейнерів і подів (частина офіційної документації Kubernetes).

2. Недооцінка перевірок життєздатності та готовності

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

Контекст: Перевірки життєздатності, готовності та запуску — це механізми, які Kubernetes використовує для моніторингу стану контейнерів та їх доступності.

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

Як уникнути цього:

Додайте просту HTTP livenessProbe, щоб перевірити точку доступу справності (наприклад, /healthz), щоб Kubernetes міг перезапустити контейнер, якщо він перестане відповідати.
Використовуйте readinessProbe, щоб забезпечити, те що трафік не досягає вашого застосунку, поки він не буде готовий.
Зберігайте перевірки простими. Надто складні перевірки можуть створити хибні сповіщення та непотрібні перезапуски.

Перевірка життям: Одного разу я забув про перевірку готовності для вебсервісу, який потребував деякого часу для завантаження. Користувачі зверталися до нього передчасно, отримували дивні тайм-аути, і я витратив години на роздуми. Три рядки перевірки готовності врятували б ситуацію.

Детальні інструкції щодо налаштування тестів на життєздатність, готовність та запуск для контейнерів див. у розділі Налаштування проб життєздатності, готовності та запуску в офіційній документації Kubernetes.

3. «Ми просто переглянемо журнали контейнерів» (відомі останні слова)

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

Як уникнути цього:

Централізуйте журнали за допомогою інструментів CNCF, таких як Fluentd або Fluent Bit, щоб агрегувати вихідні дані з усіх Podʼів.
Використовуйте OpenTelemetry для унфікованого перегляду журналів, метрик і (за потреби) трейсів. Це дозволяє виявляти кореляції між подіями інфраструктури та поведінкою на рівні застосунків.
Поєднуйте журнали з метриками Prometheus, щоб відстежувати дані на рівні кластера разом із журналами застосунків. Якщо вам потрібне розподілене трасування, розгляньте проекти CNCF, такі як Jaeger.

Перевірка життям: Коли я вперше втратив журнали Pod через швидкий перезапуск, я зрозумів, наскільки ненадійним може бути «kubectl logs» сам по собі. З того часу я налаштував належний конвеєр для кожного кластера, щоб уникнути втрати важливих підказок.

4. Однакове ставлення до оточень розробки та промислової експлуатації

Пастка: Розгортання тих самих маніфестів Kubernetes з ідентичними налаштуваннями в середовищах розробки, тестування та промислової експлуатації. Це часто відбувається, коли команди прагнуть до узгодженості та повторного використання, але не враховують, що специфічні для середовища фактори — такі як шаблони трафіку, доступність ресурсів, потреби в масштабуванні або контроль доступу, які можуть суттєво відрізнятися. Без налаштування конфігурації, оптимізовані для одного середовища, можуть викликати нестабільність, погану продуктивність або прогалини в безпеці в іншому.

Як уникнути цього:

Використовуйте оверлеї або kustomize, щоб підтримувати спільну базу, налаштовуючи запити ресурсів, репліки або конфігурацію для кожного середовища.
Витягніть специфічну для середовища конфігурацію в ConfigMaps і / або Secrets. Ви можете використовувати спеціалізований інструмент, такий як Sealed Secrets, для управління конфіденційними даними.
Плануйте масштабування в промисловому середовищі. Ваш кластер розробки, ймовірно, може обійтися мінімальними ресурсами CPU/памʼяті, але промислове середовище може потребувати значно більше.

Перевірка життям: Одного разу я збільшив replicaCount з 2 до 10 у невеликому середовищі розробки, просто щоб «перевірити». Я швидко вичерпав ресурси і півдня витратив на подолання наслідків. Ой.

5. Коли старі речі залишаються на місці

Пастка: У кластері залишаються невикористані або застарілі ресурси, такі як Deployments, Services, ConfigMaps або PersistentVolumeClaims. Це часто відбувається тому, що Kubernetes не видаляє ресурси автоматично, якщо не вказано явно, і немає вбудованого механізму для відстеження приналежності або терміну придатності. З часом ці забуті обʼєкти можуть накопичуватися, споживаючи ресурси кластера, збільшуючи витрати на хостинг у хмарі та створюючи операційну плутанину, особливо коли застарілі Services або LoadBalancers продовжують маршрутизувати трафік.

Як уникнути цього:

Позначте все мітками з метою або власником. Таким чином, ви зможете легко знайти ресурси, які вам більше не потрібні.
Регулярно перевіряйте свій кластер: запустіть kubectl get all -n <namespace>, щоб побачити, що насправді працює, і підтвердити, що все це так має бути.
Використовуйте збір сміття в Kubernetes: документація K8s показує, як автоматично видаляти залежні обʼєкти.
Використовуйте автоматизацію політики: Інструменти, такі як Kyverno, можуть автоматично видаляти або блокувати застарілі ресурси після певного періоду, або впроваджувати політики життєвого циклу, щоб вам не доводилося памʼятати про кожен окремий крок очищення.

Перевірка життям: Після хакатону я забув знести “test-svc”, привʼязаний до зовнішнього балансувальника навантаження. Три тижні потому я зрозумів, що платив за цей балансувальник навантаження весь цей час. Facepalm.

6. Занадто глибоке занурення в мережу занадто рано

Пастка: Впровадження розширених мережевих рішень, таких як сервісні мережі, власні втулки CNI або міжкластерна комунікація, до повного розуміння рідних мережевих примітивів Kubernetes. Це часто трапляється, коли команди реалізують такі функції, як маршрутизація трафіку, спостережуваність або mTLS, використовуючи зовнішні інструменти, не освоївши спочатку, як працює основна мережа Kubernetes: включаючи Pod-to-Pod комунікацію, ClusterIP сервіси, DNS-резолюцію та базову обробку вхідного трафіку. В результаті проблеми, повʼязані з мережею, стають важчими для усунення, особливо коли оверлеї вводять додаткові абстракції та точки відмови.

Як уникнути цього:

Почніть з малого: Deployment, Service та базовий контролер вхідного трафіку, наприклад, на основі NGINX (наприклад, Ingress-NGINX).
Переконайтеся, що ви розумієте, як трафік проходить у кластері, як працює виявлення сервісів і як налаштована DNS.
Переходьте до повноцінної мережі або розширених функцій CNI лише тоді, коли це дійсно необхідно, оскільки складна мережа додає накладні витрати.

Перевірка життям: Я спробував Istio на невеликому внутрішньому застосунку, а потім витратив більше часу на налагодження самого Istio, ніж на сам застосунок. Врешті-решт, я відступив, видалив Istio, і все запрацювало нормально.

7. Занадто легковажне ставлення до безпеки та RBAC

Пастка: Розгортання робочих навантажень з ненадійними конфігураціями, такими як запуск контейнерів від імені користувача root, використання теґу обрахів latest, відключення контекстів безпеки або призначення надто широких ролей RBAC, таких як cluster-admin. Ці практики зберігаються, оскільки Kubernetes не забезпечує суворі стандартні налаштування безпеки, а платформа розроблена для гнучкості, а не для жорстких обмежень. Без явних політик безпеки кластери можуть залишатися вразливими до ризиків, таких як втеча контейнерів, несанкціоноване підвищення привілеїв або випадкові зміни в промисловому середовищі через незафіксовані образи.

Як уникнути цього:

Використовуйте RBAC для визначення ролей і дозволів у Kubernetes. Хоча RBAC є стандартним і найширше підтримуваним механізмом авторизації, Kubernetes також дозволяє використовувати альтернативні авторизатори. Для більш складних або зовнішніх потреб у політиці розгляньте рішення, такі як OPA Gatekeeper (на основі Rego), Kyverno або користувацькі вебхуки з використанням мов політики, таких як CEL або Cedar.
Привʼяжіть образи до конкретних версій (більше ніякого :latest!). Це допоможе вам знати, що насправді розгорнуто.
Розгляньте Pod Security Admission (або інші рішення, такі як Kyverno), щоб забезпечити використання контейнерів без прав root, файлових систем лише для читання тощо.

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

І на останок

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

Щасливої подорожі!

Представляємо втулок Headlamp для Karpenter — масштабування та видимість

Mon, 06 Oct 2025 00:00:00 +0000

Headlamp — це відкритий, розширюваний проєкт Kubernetes SIG UI, призначений для того, щоб ви могли досліджувати, керувати та налагоджувати ресурси кластера.

Karpenter — це проєкт Kubernetes Autoscaling SIG для виділення вузлів, який допомагає кластерам швидко та ефективно масштабуватися. Він запускає нові вузли за лічені секунди, добираючи відповідні типи екземплярів для навантажень і керує повним життєвим циклом вузлів, включаючи зменшення масштабу.

Новий втулок Headlamp Karpenter додає можливість перегляду активності Karpenter у реальному часі безпосередньо з інтерфейсу Headlamp. Він показує, які ресурси Karpenter відповідають обʼєктам Kubernetes, виводить метрики в реальному часі та демонструє події масштабування в міру їх виникнення. Ви можете здійснювати перевірку подів, що очікують на обробку, переглядати рішення щодо масштабування та редагувати ресурси, що керуються Karpenter, за допомогою вбудованої функції перевірки. Втулок Karpenter був створений у рамках проєкту за підтримки LFX.

Втулок Karpenter для Headlamp має на меті спростити розуміння, налагодження та тонке налаштування поведінки автоматичного масштабування в кластерах Kubernetes. Тепер ми проведемо короткий тур по втулку Headlamp.

Мапа ресурсів Karpenter та їх звʼязки з ресурсами Kubernetes

Легко побачити, як ресурси Karpenter, такі як NodeClasses, NodePool і NodeClaims, повʼязані з основними ресурсами Kubernetes, такими як Pods, Nodes тощо.

Візуалізація метрик Karpenter

Отримайте миттєву інформацію про Resource Usage v/s Limits, Allowed disruptions, Pending Pods, Provisioning Latency та багато іншого.

Рішення щодо масштабування

Показує, які екземпляри виділяються для ваших навантажень, і допомагає зрозуміти причину, чому Karpenter прийняв ці рішення. Корисно під час налагодження.

Редактор конфігурацій з підтримкою валідації

Робіть зміни в конфігурації Karpenter в реальному часі. Редактор включає попередній перегляд змін і валідацію ресурсів для безпечніших налаштувань.

Перегляд ресурсів Karpenter у реальному часі

Переглядайте та відстежуйте специфічні ресурси Karpenter у реальному часі, такі як "NodeClaims", коли ваш кластер масштабується вгору та вниз.

Панель інструментів для подів в очікуванні

Переглядайте всі поди в очікуванні з невиконаними вимогами до планування/не вдалося запланувати, підкреслюючи причини, чому їх не вдалося запланувати.

Karpenter Providers

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

Постачальник	Перевірено	Підтримується додаткова інформація про конкретного постачальника
AWS	✅	✅
Azure	✅	✅
AlibabaCloud	❌	❌
Bizfly Cloud	❌	❌
Cluster API	❌	❌
GCP	❌	❌
Proxmox	❌	❌
Oracle Cloud Infrastructure (OCI)	❌	❌

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

Як користуватися

Будь ласка, ознайомтеся з plugins/karpenter/README.md для отримання інструкцій щодо використання.

Відгуки та запитання

Будь ласка, стовріть тікет якщо ви використовуєте Karpenter і маєте будь-які інші ідеї або відгуки. Або приєднуйтесь до каналу Kubernetes slack headlamp для спілкування.

Оголошення про підтримку Changed Block Tracking API (альфа)

Thu, 25 Sep 2025 05:00:00 -0800

Ми раді оголосити про альфа-підтримку механізму відстеження змінених блоків. Це покращує екосистему зберігання даних Kubernetes, надаючи ефективний спосіб для драйверів зберігання даних CSI ідентифікувати змінені блоки в знімках (snapshot) PersistentVolume. За допомогою драйвера, який може використовувати цю функцію, ви зможете скористатися швидшими та більш ефективними з точки зору використання ресурсів операціями резервного копіювання.

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

Що таке відстеження змінених блоків?

Відстеження змінених блоків дозволяє системам зберігання даних ідентифікувати та відстежувати зміни на рівні блоків між моментальними знімками, усуваючи необхідність сканування цілих томів під час операцій резервного копіювання. Це вдосконалення є зміною в інтерфейсі Container Storage Interface (CSI), а також у підтримці зберігання даних у самій системі Kubernetes. З увімкненою альфа-функцією ваш кластер може:

Ідентифікувати виділені блоки в знімку тому CSI
Визначати змінені блоки між двома знімками одного тому
Оптимізувати операції резервного копіювання, зосередившись лише на змінених блоках даних

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

Примітка:

На даний момент Changed Block Tracking API підтримується тільки для блокових томів, а не для файлових томів. Драйвери CSI, які керують файловими системами зберігання даних, не зможуть реалізувати цю функцію.

Переваги підтримки відстеження змінених блоків у Kubernetes

У міру зростання популярності Kubernetes для управління критичними даними зі збереженням стану (stateful), потреба в ефективних рішеннях для резервного копіювання стає все більш важливою. Традиційні підходи до повного резервного копіювання стикаються з такими проблемами:

Довгі вікна резервного копіювання: повне резервне копіювання великих обсягів даних може займати години, що ускладнює його виконання в межах вікон технічного обслуговування.
Високе використання ресурсів: операції резервного копіювання споживають значну пропускну здатність мережі та ресурси вводу-виводу, особливо для великих обсягів даних і застосунків, що інтенсивно використовують дані.
Збільшення витрат на зберігання: Повторні повні резервні копії зберігають надлишкові дані, що призводить до лінійного зростання вимог до зберігання, навіть якщо між резервними копіями фактично змінюється лише невеликий відсоток даних.

Changed Block Tracking API вирішує ці проблеми, надаючи вбудовану підтримку Kubernetes для інкрементних резервних копій через інтерфейс CSI.

Ключові компоненти

Реалізація складається з трьох основних компонентів:

CSI SnapshotMetadata Service API: API, що пропонується gRPC, який надає знімки томів та дані про змінені блоки.
SnapshotMetadataService API: Kubernetes CustomResourceDefinition (CRD), який повідомляє про доступність служби метаданих драйвера CSI та деталі підключення до клієнтів кластера.
External Snapshot Metadata Sidecar: проміжний компонент, який підключає драйвери CSI до застосунків резервного копіювання через стандартизований інтерфейс gRPC.

Вимоги до впровадження

Обовʼязки постачальника послуг зберігання

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

Впровадити CSI RPC: Постачальники систем зберігання даних повинні впровадити сервіс SnapshotMetadata, як визначено в специфікаціях CSI protobuf. Цей сервіс вимагає впровадження серверного потокового передавання для таких RPC:
- GetMetadataAllocated: для ідентифікації виділених блоків у знімку
- GetMetadataDelta: для визначення змінених блоків між двома знімками
Можливості бекенду сховища: переконайтеся, що бекенд сховища має можливість відстежувати та повідомляти про зміни на рівні блоків.
Розгортання зовнішніх компонентів: інтегруйте з sidecar external-snapshot-metadata, щоб відкрити доступ до сервісу метаданих знімків.
Реєстрація власного ресурсу: зареєструйте ресурс SnapshotMetadataService за допомогою CustomResourceDefinition і створіть власний ресурс SnapshotMetadataService, який повідомляє про доступність служби метаданих і надає деталі підключення.
Підтримка обробки помилок: реалізуйте належну обробку помилок для цих RPC відповідно до вимог специфікації CSI.

Відповідальність за рішення щодо резервного копіювання

A backup solution looking to leverage this feature must:

Налаштування автентифікації: Програма резервного копіювання повинна надавати токен Kubernetes ServiceAccount під час використання Kubernetes SnapshotMetadataService API. Необхідно встановити відповідні права доступу, такі як RBAC RoleBindings, щоб авторизувати ServiceAccount програми резервного копіювання для отримання таких токенів.
Впровадити код потокового передавання на стороні клієнта: Розробити клієнти, які впроваджують API потокового передавання gRPC, визначені у файлі schema.proto. Зокрема:
- Впровадити код клієнта для потокового передавання для методів GetMetadataAllocated та GetMetadataDelta.
- Ефективно обробляти відповіді сервера для потокового передавання, оскільки метадані надходять частинами.
- Обробляти формат повідомлення SnapshotMetadataResponse з належним обробленням помилок.
Репозиторій GitHub external-snapshot-metadata надає зручний пакет підтримки ітератора для спрощення реалізації клієнта.
Обробка великих потоків даних: Розробка клієнтів для ефективної обробки великих потоків метаданих блоків, які можуть бути повернуті для томів із значними змінами.
Оптимізація процесів резервного копіювання: Модифікація робочих процесів резервного копіювання для використання змінених метаданих блоків з метою ідентифікації та передачі лише змінених блоків, щоб зробити резервне копіювання більш ефективним, скоротивши тривалість резервного копіювання та споживання ресурсів.

Початок роботи

Щоб використовувати відстеження змінених блоків у кластері:

Переконайтеся, що драйвер CSI підтримує знімки томів і реалізує можливості метаданих знімків за допомогою необхідного sidecar external-snapshot-metadata.
Переконайтеся, що власний ресурс SnapshotMetadataService зареєстрований за допомогою CRD.
Перевірте наявність власного ресурсу SnapshotMetadataService для драйвера CSI.
Створіть клієнтів, які можуть отримати доступ до API за допомогою відповідної автентифікації (через токени Kubernetes ServiceAccount).

API надає дві основні функції:

GetMetadataAllocated: перелічує блоки, виділені в одному знімку.
GetMetadataDelta: перелічує блоки, змінені між двома знімками.

Що далі?

Залежно від відгуків та прийняття, розробники Kubernetes сподіваються перевести реалізацію CSI Snapshot Metadata в бета-версію в майбутніх релізах.

Де я можу дізнатися більше?

Для тих, хто зацікавлений у випробуванні цієї нової функції:

Офіційна документація для розробників Kubernetes CSI
Пропозиція щодо вдосконалення функції метаданих знімків.
Репозиторій GitHub для реалізації та статусу випуску external-snapshot-metadata
Повні визначення протоколу gRPC для API метаданих знімків: schema.proto
Приклад реалізації клієнта метаданих знімків: snapshot-metadata-lister
Приклад комплексного рішення з csi-hostpath-driver: документація з прикладом

Як я можу долучитися?

Цей проєкт, як і всі проєкти Kubernetes, є результатом наполегливої праці багатьох учасників з різних сфер, які працювали разом. Від імені SIG Storage я хотів би висловити величезну подяку учасникам, які допомогли переглянути дизайн та реалізацію проєкту, зокрема, але не виключно, наступним особам:

Ben Swartzlander (bswartz)
Carl Braganza (carlbraganza)
Daniil Fedotov (hairyhum)
Ivan Sim (ihcsim)
Nikhil Ladha (Nikhil-Ladha)
Prasad Ghangal (PrasadG193)
Praveen M (iPraveenParihar)
Rakshith R (Rakshith-R)
Xing Yang (xing-yang)

Дякуємо також усім, хто долучився до проєкту, зокрема тим, хто допоміг рецензувати KEP та CSI spec PR.

Ті, хто зацікавлений у розробці та розвитку CSI або будь-якої частини системи зберігання даних Kubernetes, можуть приєднатися до Kubernetes Storage Special Interest Group (SIG). Ми завжди раді новим учасникам.

SIG також проводить регулярні зустрічі Data Protection Working Group. Нові учасники можуть долучитися до наших дискусій.

Kubernetes v1.34: Ресурси рівня Pod перейшли в стадію бета

Mon, 22 Sep 2025 10:30:00 -0800

Від імені спільноти Kubernetes я з радістю повідомляю, що функція Pod Level Resources (Ресурси рівня Pod) перейшла в стадію бета у версії Kubernetes v1.34 і є стандартно увімкненою! Ця важлива подія відкриває нові можливості для визначення та управління розподілом ресурсів для ваших Podʼів. Така гнучкість зумовлена можливістю вказати ресурси CPU та памʼяті для Podʼа в цілому. Ресурси на рівні Podʼа можна поєднувати зі специфікаціями на рівні контейнера, щоб точно визначити вимоги до ресурсів та обмеження, необхідні для вашого застосунку.

Специфікація ресурсів на рівні Podʼа

До недавнього часу специфікації ресурсів, що застосовувалися до Podʼа, визначалися переважно на рівні окремих контейнерів. Хоча такий підхід був ефективним, іноді він вимагав дублювання або ретельного розрахунку потреб у ресурсах для декількох контейнерів в одному Podʼі. У якості бета-функції Kubernetes дозволяє визначати ресурси CPU, памʼяті та hugepages на рівні Podʼа. Це означає, що тепер ви можете визначати запити та обмеження ресурсів для всього Podʼа, що спрощує спільне використання ресурсів без необхідності детального управління цими ресурсами для кожного контейнера, де це не потрібно.

Чому важливі специфікації на рівні Podʼа?

Ця функція покращує управління ресурсами в Kubernetes, пропонуючи гнучке управління ресурсами як на рівні Podʼів, так і на рівні контейнерів.

Вона забезпечує консолідований підхід до оголошення ресурсів, зменшуючи необхідність ретельного управління кожним контейнером окремо, особливо для Podʼів з декількома контейнерами.
Ресурси на рівні Podʼа дозволяють контейнерам у Podʼі обмінюватися між собою невикористаними ресурсами, сприяючи ефективному використанню ресурсів у Podʼі. Наприклад, це запобігає перетворенню контейнерів-sidecar на вузькі місця, що обмежують продуктивність. Раніше sidecar (наприклад, агент логування або проксі сервісної мережі), що досягали свого індивідуального обмеження CPU, могли бути стишені і сповільнювати роботу всього Podʼа, навіть якщо основний контейнер застосунку мав достатньо вільного CPU. За допомогою ресурсів на рівні Podʼа sidecarʼи та основний контейнер можуть спільно використовувати ресурси Podʼа, забезпечуючи безперебійну роботу під час пікових навантажень — або весь Pod стишується, або всі контейнери працюють.
Коли вказані ресурси як на рівні подів, так і на рівні контейнерів, пріоритет мають запити та обмеження на рівні подів. Це надає вам та адміністраторам кластерів потужний засіб для забезпечення загальних обмежень ресурсів для ваших Podʼів.

Для планування, якщо запит на рівні подів явно визначений, планувальник використовує це конкретне значення для пошуку відповідного вузла, а не сукупні запити окремих контейнерів. Під час виконання обмеження на рівні подів діє як жорстка верхня межа для сукупного використання ресурсів усіма контейнерами. Важливо, що це обмеження на рівні подів є абсолютним; навіть якщо сума індивідуальних обмежень контейнерів є вищою, загальне споживання ресурсів ніколи не може перевищити обмеження на рівні подів.
Ресурси на рівні Podʼів мають пріоритет у впливі на клас якості обслуговування (QoS) Podʼа.
Для Podʼів, що працюють на вузлах Linux, при розрахунку коригування показника Out-Of-Memory (OOM) враховуються запити на ресурси як на рівні Podʼа, так і на рівні контейнера.
Ресурси на рівні Pod спроєктовані для сумісності з наявними функціональними можливостями Kubernetes, що забезпечує плавну інтеграцію у ваші робочі процеси.

Як вказати ресурси для всього Pod

Використання функціональної можливості PodLevelResources вимагає Kubernetes v1.34 або новішої версії для всіх компонентів кластера, включаючи панель управління та кожен вузол. Ця функція знаходиться в бета-версії та є стандартно увімкненою у v1.34.

Приклад маніфесту

Ви можете вказати ресурси CPU, памʼяті та hugepages безпосередньо в маніфесті специфікації Podʼа у полі resources для всього Podʼа.

Ось приклад, що демонструє Pod із запитами та обмеженнями CPU та памʼяті, визначеними на рівні Pod:

apiVersion: v1
kind: Pod
metadata:
  name: pod-resources-demo
  namespace: pod-resources-example
spec:
  # Поле 'resources' на рівні специфікації Podʼа визначає загальний
  # бюджет ресурсів для всіх контейнерів у цьому Podʼі разом.
  resources: # Ресурси на рівні Podʼа
    # 'limits' визначає максимальну кількість ресурсів, яку може використовувати Pod.
    # Сума обмежень усіх контейнерів у Podʼі не може перевищувати ці значення.
    limits:
      cpu: "1" # Весь Pod не може використовувати більше 1 ядро процесора.
      memory: "200Mi" # Весь Pod не може використовувати більше 200 МБ памʼяті.
    # 'requests' визначає мінімальний обсяг ресурсів, гарантований Podʼу.
    # Це значення використовується планувальником Kubernetes для пошуку вузла з достатньою ємністю.
    requests:
      cpu: "1" # Pod гарантовано отримує 1 ядро процесора при плануванні.
      memory: "100Mi" # При плануванні Pod гарантується 100 МБ памʼяті.
  containers:
  - name: main-app-container
    image: nginx
    ...
    # Для цього контейнера не вказано жодних запитів на ресурси або обмежень.
  - name: auxiliary-container
    image: fedora
    command: ["sleep", "inf"]
    ...
    # Для цього контейнера не вказано жодних запитів на ресурси або обмежень.

У цьому прикладі Pod pod-resources-demo в цілому запитує 1 CPU і 100 MiB памʼяті, і обмежений 1 CPU і 200 MiB памʼяті. Контейнери всередині будуть працювати в рамках цих загальних обмежень на рівні Podʼа, як пояснено в наступному розділі.

Взаємодія з запитами або обмеженнями ресурсів на рівні контейнера

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

Розглянемо Pod з двома контейнерами, де визначені запити та обмеження на рівні podʼа щодо CPU та памʼяті, і лише один контейнер має власні явні визначення ресурсів:

apiVersion: v1
kind: Pod
metadata:
  name: pod-resources-demo
  namespace: pod-resources-example
spec:
  resources:
    limits:
      cpu: "1"
      memory: "200Mi"
    requests:
      cpu: "1"
      memory: "100Mi"
  containers:
  - name: main-app-container
    image: nginx
    resources:
      requests:
        cpu: "0.5"
        memory: "50Mi"
  - name: auxiliary-container
    image: fedora
    command: [ "sleep", "inf"]
    # Для цього контейнера не вказано жодних запитів на ресурси або обмежень.

Обмеження на рівні Podʼа: Обмеження на рівні Podʼа (cpu: "1", memory: "200Mi") встановлюють абсолютну межу для всього Podʼа. Сума ресурсів, що споживаються всіма його контейнерами, обмежується цією межею і не може бути перевищена.
Спільне використання та перевищення ресурсів: контейнери можуть динамічно запозичувати будь-яку невикористану потужність, що дозволяє їм перевищувати обмеження за потреби, якщо сукупне використання Podʼа залишається в межах загального обмеження.
Запити на рівні Pod: запити на рівні Pod (cpu: "1", memory: "100Mi") слугують основою для гарантування ресурсів для всього Podʼа. Це значення впливає на рішення планувальника щодо розміщення і представляє мінімальні ресурси, на які Pod може розраховувати під час конфлікту на рівні вузла.
Запити на рівні контейнера: запити на рівні контейнера створюють систему пріоритетів у межах гарантованого бюджету Podʼа. Оскільки main-app-container має явний запит (cpu: "0.5", memory: "50Mi"), йому надається пріоритет у розподілі ресурсів під тиском ресурсів над auxiliary-container, який не має такого явного запиту.

Обмеження

По-перше, зміна на місці розміру ресурсів на рівні pod не підтримується для Kubernetes v1.34 (або раніше). Спроба змінити обмеження або запити ресурсів на рівні podʼа для працюючого Podʼа призводить до помилки: зміна розміру відхиляється. Реалізація ресурсів на рівні Podʼа у версії v1.34 зосереджена на тому, щоб дозволити початкове оголошення загального ресурсного конверту, який застосовується до всього Podʼа. Це відрізняється від зміни розміру на місці, яка (незважаючи на те, що може натякати назва) дозволяє динамічно коригувати запити та обмеження ресурсів контейнера в працюючому Podʼі і, можливо, без перезапуску контейнера. Зміна розміру на місці також ще не є стабільною функцією; вона перейшла в стадію бета у версії v1.33.
На рівні pod можна вказати лише ресурси CPU, памʼяті та великі сторінки (hugepages).
Ресурси на рівні pod не підтримуються для podʼів Windows. Якщо специфікація Podʼа явно націлена на Windows (наприклад, шляхом встановлення spec.os.name: "windows"), сервер API відхилить Pod під час етапу перевірки. Якщо под явно не позначений для Windows, але запланований для вузла Windows (наприклад, за допомогою nodeSelector), Kubelet на цьому вузлі Windows відхилить под під час процесу допуску.
Менеджер топології, менеджер памʼяті та менеджер процесора не вирівнюють под і контейнери на основі ресурсів на рівні пода, оскільки ці менеджери ресурсів наразі не підтримують ресурси на рівні пода.

Початок роботи та надання відгуків

Готові ознайомитися з функцією Pod Level Resources? Вам знадобиться кластер Kubernetes з версією 1.34 або пізнішою. Не забудьте увімкнути функціональну можливість PodLevelResources у вашій панелі управління та на всіх вузлах.

Оскільки ця функція перебуває на стадії бета-тестування, ваші відгуки є надзвичайно цінними. Будь ласка, повідомляйте про будь-які проблеми або діліться своїм досвідом через стандартні канали комунікації Kubernetes:

Kubernetes v1.34: Відновлення після збою розширення тому (GA)

Fri, 19 Sep 2025 10:30:00 -0800

Чи робили ви коли-небудь помилку при розширенні ваших постійних томів у Kubernetes? Хотіли вказати 2TB, але вказали 20TiB? Ця, здавалося б, незначна проблема була досить важкою для виправлення, і проєкту знадобилося майже 5 років, щоб її виправити. Автоматичне відновлення після розширення сховища існує вже деякий час у бета-версії; однак, з випуском v1.34, ми перевели її в загальну доступність.

Хоча завжди було можливо відновитися після збою розширення томів вручну, зазвичай це вимагало доступу адміністратора кластера і було нудно робити (див. вказане посилання для отримання додаткової інформації).

Що, якщо ви зробите помилку, а потім відразу усвідомите це? З Kubernetes v1.34 ви повинні мати можливість зменшити запитуваний розмір PersistentVolumeClaim (PVC) і, якщо розширення до раніше запитуваного розміру не завершилося, ви можете змінити запитуваний розмір. Kubernetes автоматично працюватиме над його виправленням. Будь-яка квота, спожита невдалим розширенням, буде повернена користувачу, а повʼязаний PersistentVolume повинен бути змінений на останній вказаний вами розмір.

Я пройду через приклад того, як все це працює.

Зменшення розміру PVC для відновлення після невдалого розширення

Уявіть, що у вас закінчується місце на диску для одного з ваших серверів бази даних, і ви хочете розширити PVC з раніше вказаного 10TB до 100TB, але ви зробили помилку і вказали 1000TB.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1000TB # новий вказаний розмір - але неправильний!

Тепер у вас може закінчитися місце на диску в масиві дисків або просто вичерпані виділені квоти у вашого постачальника хмари. Але припустимо, що розширення до 1000TB ніколи не відбудеться.

У Kubernetes v1.34 ви можете просто виправити свою помилку і запитати новий розмір PVC, який менший за помилку, за умови, що він все ще більший за початковий розмір фактичного PersistentVolume.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100TB # Правильний розмір; має бути більшим за 10TB.
                     # Ви не можете зменшити обсяг нижче його фактичного розміру.

Це не вимагає втручання адміністратора. Ще краще, будь-яка надлишкова квота Kubernetes, яку ви тимчасово спожили, буде автоматично повернена.

Цей механізм відновлення після збоїв має одну умову: будь-який новий розмір, який ви вказуєте для PVC, повинен бути все ще більшим за початковий розмір у .status.capacity. Оскільки Kubernetes не підтримує зменшення ваших обʼєктів PV, ви ніколи не зможете зменшити їх до розміру, який спочатку був виділений для вашого запиту PVC.

Поліпшене оброблення помилок і спостережуваність розширення томів

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

Поліпшена спостережуваність за розширенням у процесі

Ви можете запитати .status.allocatedResourceStatus['storage'] PVC, щоб відстежувати прогрес операції розширення томів. Для типового блочного тому це має переходити між ControllerResizeInProgress, NodeResizePending і NodeResizeInProgress і ставати nil/порожнім, коли розширення томів завершено.

Якщо з якоїсь причини розширення томів до запитаного розміру неможливе, воно повинно відповідно перебувати в станах, таких як ControllerResizeInfeasible або NodeResizeInfeasible.

Ви також можете спостерігати за розміром, до якого Kubernetes працює, спостерігаючи за pvc.status.allocatedResources.

Поліпшене оброблення помилок і звітність

Kubernetes тепер повинен повторно спробувати ваші невдалі розширення томів повільніше, він повинен робити менше запитів як до системи зберігання, так і до Kubernetes apiserver.

Помилки, виявлені під час розширення томів, тепер повідомляються як стан на обʼєктах PVC і повинні зберігатися на відміну від подій. Kubernetes тепер заповнить pvc.status.conditions ключами помилок ControllerResizeError або NodeResizeError, коли розширення томів не вдається.

Виправлення давніх помилок у робочих процесах зміни розміру

Ця функція також дозволила нам виправити давні помилки в робочих процесах зміни розміру, такі як Kubernetes issue #115294. Якщо ви спостерігаєте щось зламане, будь ласка, повідомте про свої помилки на https://github.com/kubernetes/kubernetes/issues, разом з деталями про те, як відтворити проблему.

Робота над цією функцією протягом її життєвого циклу була складною, і було б неможливо досягти GA без зворотного звʼязку від @msau42, @jsafrane і @xing-yang.

Всі учасники, які працювали над цим, також цінують внесок, наданий @thockin і @liggitt на різних самітах контрибʼюторів Kubernetes.

Kubernetes v1.34: Споживча ємність DRA

Thu, 18 Sep 2025 10:30:00 -0800

Динамічне виділення ресурсів (Dynamic Resource Allocation, DRA) — це API Kubernetes для управління дефіцитними ресурсами Podʼів та контейнерів. Він дозволяє гнучкі запити ресурсів, виходячи за межі простого виділення N кількості пристроїв, щоб підтримувати більш детальні сценарії використання. З DRA користувачі можуть запитувати специфічні типи пристроїв на основі їх атрибутів, визначати власні конфігурації, адаптовані до їх робочих навантажень, і навіть ділитися одним і тим же ресурсом між кількома контейнерами або Podʼами.

Тут ми зосередимося на функції спільного використання пристроїв і заглибимось в нову можливість, представлену в Kubernetes 1.34: споживча ємність DRA, яка розширює DRA для підтримки більш тонкого спільного використання пристроїв.

Передумови: спільне використання пристроїв через ResourceClaims

З самого початку DRA представила можливість для кількох Podʼів ділитися пристроєм, посилаючись на один і той же ResourceClaim. Цей дизайн відокремлює виділення ресурсів від конкретного обладнання, що дозволяє більш динамічне та повторне використання пристроїв.

У Kubernetes 1.33 нова підтримка розділювальних пристроїв (partitionable devices) дозволила драйверам ресурсів оголошувати частини пристрою, які доступні, а не виставляти весь пристрій як ресурс "все або нічого". Це дозволило Kubernetes більш точно моделювати обладнання спільного використання.

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

Саме тут зʼявляється споживча ємність для DRA.

Переваги підтримки споживчої ємності DRA

Ось короткий огляд того, що ви отримуєте в кластері з увімкненою функціональною можливістю DRAConsumableCapacity.

Спільне використання пристроїв між кількома ResourceClaims або DeviceRequests

Тепер драйвери ресурсів можуть підтримувати спільне використання одного й того ж пристрою, або навіть частини пристрою, між кількома ResourceClaims або між кількома DeviceRequests.

Це означає, що Podʼи з різних просторів імен можуть одночасно ділитися одним і тим же пристроєм, якщо це дозволено та підтримується конкретним драйвером DRA.

Виділення ресурсів пристроїв

Kubernetes розширює алгоритм виділення в планувальнику, щоб підтримувати виділення частини ресурсів пристрою, як визначено в полі capacity. Планувальник забезпечує, щоб загальна виділена ємність для всіх споживачів ніколи не перевищувала загальну ємність пристрою, навіть коли вона ділиться між кількома ResourceClaims або DeviceRequests. Це дуже схоже на те, як планувальник дозволяє Podʼам і контейнерам ділитися виділеними ресурсами на вузлах; в цьому випадку він дозволяє їм ділитися виділеними ресурсами на пристроях.

Ця функція розширює підтримку сценаріїв, де драйвер пристрою може керувати ресурсами всередині пристрою та на основі кожного процесу — наприклад, виділення певної кількості памʼяті (наприклад, 8 ГіБ) з віртуального GPU, або встановлення обмежень пропускної здатності на віртуальні мережеві інтерфейси, виділені конкретним Podʼам. Це має на меті забезпечити безпечне та ефективне спільне використання ресурсів.

Обмеження DistinctAttribute

Ця функція також вводить нове обмеження: DistinctAttribute, яке є доповненням до наявного обмеження MatchAttribute.

Основна мета DistinctAttribute полягає в тому, щоб запобігти багаторазовому виділенню одного й того ж базового пристрою в межах одного ResourceClaim, що може статися, оскільки ми виділяємо частки (або підмножини) пристроїв. Це обмеження забезпечує, щоб кожне виділення посилалося на окремий ресурс, навіть якщо вони належать до одного й того ж класу пристроїв.

Це корисно для таких випадків, як виділення мережевих пристроїв, що підключаються до різних підмереж, щоб розширити покриття або забезпечити резервування в різних зонах відмов.

Як використовувати споживчу ємність?

DRAConsumableCapacity була представлена як альфа-функція в Kubernetes 1.34. Функціональна можливість DRAConsumableCapacity має бути увімкнена в kubelet, kube-apiserver, kube-scheduler і kube-controller-manager.

--feature-gates=...,DRAConsumableCapacity=true

Як розробник драйвера DRA

Як розробник драйвера DRA, що пише на Golang, ви можете зробити пристрій у межах ResourceSlice доступним для кількох ResourceClaims (або devices.requests), встановивши AllowMultipleAllocations на true.

Device {
  ...
  AllowMultipleAllocations: ptr.To(true),
  ...
}

Додатково, ви можете визначити політику, щоб обмежити те, як кожен DeviceRequest повинен споживати Capacity кожного пристрою, визначивши поле RequestPolicy у DeviceCapacity. Приклад нижче показує, як визначити політику, яка вимагає, щоб GPU з 40 ГіБ памʼяті виділяв щонайменше 5 ГіБ на запит, при цьому кожне виділення має бути кратним 5 ГіБ.

DeviceCapacity{
  Value: resource.MustParse("40Gi"),
  RequestPolicy: &CapacityRequestPolicy{
    Default: ptr.To(resource.MustParse("5Gi")),
    ValidRange: &CapacityRequestPolicyRange {
      Min: ptr.To(resource.MustParse("5Gi")),
      Step: ptr.To(resource.MustParse("5Gi")),
    }
  }
}

Це буде опубліковано в ResourceSlice, як частково показано нижче:

apiVersion: resource.k8s.io/v1
kind: ResourceSlice
...
spec:
  devices:
  - name: gpu0
    allowMultipleAllocations: true
    capacity:
      memory:
        value: 40Gi
        requestPolicy:
          default: 5Gi
          validRange:
            min: 5Gi
            step: 5Gi

Віділений пристрій з певною часткою спожитої ємності матиме поле ShareID, встановлене в статусі виділення.

claim.Status.Allocation.Devices.Results[i].ShareID

Цей ShareID дозволяє драйверу розрізняти різні віділення, які посилаються на той самий пристрій або той самий статично виділений сегмент, але походять з різних запитів ResourceClaim. Він діє як унікальний ідентифікатор для кожного спільного сегмента, дозволяючи драйверу незалежно керувати та застосовувати обмеження ресурсів для декількох споживачів.

Як споживач

Як споживач (або користувач), ресурс пристрою можна запитати за допомогою ResourceClaim, як показано нижче:

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
...
spec:
  devices:
    requests: # для пристроїв
    - name: req0
      exactly:
        deviceClassName: resource.example.com
        capacity:
          requests: # для ресурсів, які повинні бути надані цими пристроями
            memory: 10Gi

Ця конфігурація забезпечує, що запитуваний пристрій може надати щонайменше 10ГіБ памʼяті.

Зокрема, будь-який пристрій resource.example.com, який має щонайменше 10ГіБ памʼяті, може бути виділений. Якщо вибрано пристрій, який не підтримує кілька виділень, виділення використовуватиме весь пристрій. Щоб відфільтрувати лише пристрої, які підтримують кілька виділень, ви можете визначити селектор, як показано нижче:

selectors:
  - cel:
      expression: |-
        device.allowMultipleAllocations == true

Інтеграція зі статусом пристроїв DRA

У спільному використанні пристроїв загальна інформація про пристрій надається через ресурсний зріз. Однак деякі деталі встановлюються динамічно після виділення. Ці дані можна передати за допомогою поля .status.devices у ResourceClaim. Це поле публікується лише в кластерах, де увімкнено DRAResourceClaimDeviceStatus feature gate.

Якщо у вас є підтримка статусу пристроїв, драйвер може надати додаткову інформацію про пристрій, виходячи за межі ShareID. Одним із особливо корисних випадків є віртуальні мережі, де драйвер може включити призначену IP-адресу(и) у статус. Це цінно як для операцій мережевих служб, так і для усунення несправностей.

Ви можете знайти більше інформації, переглянувши нашу запис: KubeCon Japan 2025 — Reimagining Cloud Native Networks: The Critical Role of DRA.

Що ви можете зробити далі?

Перегляньте проєкт CNI DRA Driver для прикладу інтеграції DRA в мережі Kubernetes. Спробуйте інтегруватися з мережевими ресурсами, такими як macvlan, ipvlan або смарт NIC.
Увімкніть функціональну можливість DRAConsumableCapacity та експериментуйте з віртуалізованими або роздільними пристроями. Визначте свої робочі навантаження з споживаною ємністю (наприклад: дробова пропускна здатність або памʼять).
Дайте нам знати вашу думку:
- ✅ Що спрацювало добре?
- ⚠️ Що не спрацювало?
Якщо ви зіткнулися з проблемами, які потрібно виправити, або можливостями для вдосконалення, будь ласка, створіть новий тікет і посилайтеся та пошліться на KEP-5075 там, або звʼяжіться з нами через Slack (#wg-device-management).

Висновок

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

Спробуйте це, експериментуйте зі споживаними ресурсами та допоможіть сформувати майбутнє динамічного виділення ресурсів у Kubernetes!

Додатково ознайомтеся з

Kubernetes v1.34: Звіт про стан ресурсів DRA в Podʼах

Wed, 17 Sep 2025 10:30:00 -0800

Зростання популярності штучного інтелекту (AI) та машинного навчання (ML) та інших високопродуктивних робочих навантажень зробило спеціалізоване обладнання, таке як графічні процесори (GPU), процесори для обробки даних (TPU) та програмовані логічні матриці (FPGA), критично важливим компонентом багатьох кластерів Kubernetes. Однак, як обговорювалося в попередньому блозі про пошук збоїв у Podʼах з пристроями, коли це обладнання виходить з ладу, його може бути важко діагностувати, що призводить до значного часу простою. З випуском Kubernetes v1.34 ми раді оголосити про нову альфа-функцію, яка забезпечує необхідну видимість стану цих пристроїв.

Ця робота розширює функціональність KEP-4680, яка вперше представила механізм для звітування про стан пристроїв, що керуються втулками пристроїв. Тепер ця можливість розширюється на Динамічне виділення ресурсів (DRA). Контрольована через функціональну можливість ResourceHealthStatus, це вдосконалення дозволяє драйверам DRA звітувати про стан пристроїв безпосередньо в поле .status Podʼа, надаючи важливу інформацію для операторів і розробників.

Чому важливо показувати стан пристроїв у статусі Podʼа?

Для стану застосунків або тривалих завдань збій пристрою може бути руйнівним і витратним. Експонуючи стан пристроїв у полі .status для Podʼа, Kubernetes надає стандартизований спосіб для користувачів і автоматизованих інструментів швидко діагностувати проблеми. Якщо Pod зазнає збою, ви тепер можете перевірити його статус, щоб дізнатися, чи є несправний пристрій основною причиною, заощаджуючи цінний час, який інакше міг би бути витрачений на налагодження коду застосунку.

Як це працює

Ця функція вводить новий, необовʼязковий канал звʼязку між Kubelet і драйверами DRA, побудований на трьох основних компонентах.

Новий gRPC сервіс перевірки справності

Новий gRPC сервіс, DRAResourceHealth, визначено в групі API dra-health/v1alpha1. Драйвери DRA можуть реалізувати цей сервіс для потокової передачі оновлень стану пристроїв до Kubelet. Сервіс включає серверний стрім RPC NodeWatchResources, який надсилає статус справності (Healthy, Unhealthy або Unknown) для пристроїв, якими він керує.

Інтеграція з Kubelet

Менеджер втулків DRA в Kubelet виявляє, які драйвери реалізують сервіс перевірки справності. Для кожного сумісного драйвера він запускає довготривалий стрім NodeWatchResources, щоб отримувати оновлення стану. Менеджер DRA потім споживає ці оновлення та зберігає їх у постійному кеші healthInfoCache, який може пережити перезавантаження Kubelet.

Заповнення статусу Podʼа

Коли стан пристрою змінюється, менеджер DRA ідентифікує всі Podʼи, на які вплинула зміна, і ініціює оновлення статусу Podʼа. Нове поле, allocatedResourcesStatus, тепер є частиною обʼєкта API v1.ContainerStatus. Kubelet заповнює це поле поточним станом кожного пристрою, виділеного контейнеру.

Практичний приклад

Якщо Pod знаходиться в стані CrashLoopBackOff, ви можете використовувати kubectl describe pod <pod-name>, щоб перевірити його статус. Якщо виділений пристрій зазнав збою, вивід тепер включатиме поле allocatedResourcesStatus, чітко вказуючи на проблему:

status:
  containerStatuses:
  - name: my-gpu-intensive-container
    # ... інші стани контейнерів
    allocatedResourcesStatus:
    - name: "claim:my-gpu-claim"
      resources:
      - resourceID: "example.com/gpu-a1b2-c3d4"
        health: "Unhealthy"

Цей явний статус чітко вказує на те, що проблема полягає в апаратному забезпеченні, а не в застосунку.

Тепер ви можете вдосконалити логіку виявлення збоїв, щоб реагувати на несправні пристрої, повʼязані з Podʼом, скасування планування Podʼа.

Як використовувати цю функцію

Оскільки це альфа-функція в Kubernetes v1.34, ви повинні виконати такі кроки, щоб використовувати її:

Увімкніть функціональну можливість ResourceHealthStatus на вашому kube-apiserver та kubelet.
Переконайтеся, що ви використовуєте драйвер DRA, який реалізує gRPC сервіс v1alpha1 DRAResourceHealth.

Драйвери DRA

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

Що далі?

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

Детальні повідомлення про стан справності: Щоб покращити досвід налагодження, ми плануємо додати поле з повідомленням зрозумілими людям до gRPC API. Це дозволить драйверам DRA надавати конкретний контекст для стану справності, наприклад, "Температура GPU перевищує поріг" або "Зʼєднання NVLink втрачено".
Конфігуровані тайм-аути перевірки справності: Тайм-аут для позначення стану справності пристрою як "Unknown" наразі жорстко прописаним у коді. Ми плануємо зробити це конфігурованим, ймовірно, на основі кожного драйвера, щоб краще врахувати різні характеристики звітності про стан справності різного апаратного забезпечення.
Покращене усунення несправностей після виходу з ладу: Ми вирішимо відому обмеженість, коли оновлення стану справності можуть не застосовуватися до Podʼів, які вже завершили свою роботу. Це виправлення забезпечить збереження стану справності пристрою на момент збою, що є критично важливим для налагодження пакетних завдань та інших "завдань, що виконуються до завершення".

Ця функція була розроблена в рамках KEP-4680, і відгуки спільноти є критично важливими, оскільки ми працюємо над її переходом до бета-версії. Ми маємо більше вдосконалень обробки збоїв пристроїв у k8s і закликаємо вас спробувати це та поділитися своїм досвідом з спільнотою SIG Node!

Kubernetes v1.34: Volume Group Snapshots переходить в v1beta2

Tue, 16 Sep 2025 10:30:00 -0800

Volume group snapshots було представлено як функцію Alpha у випуску Kubernetes 1.27, зміна у Beta — у випуску Kubernetes 1.32. Останній випуск Kubernetes v1.34 переніс цю підтримку на другий бета-етап. Підтримка знімків групи томів спирається на набір додаткових API для групових знімків. Ці API дозволяють користувачам робити знімки, що відповідають аварійним ситуаціям, для набору томів. За лаштунками Kubernetes використовує селектор міток для групування кількох PersistentVolumeClaims для знімків. Основна мета полягає в тому, щоб дозволити вам відновити цей набір знімків на нові томи та відновити вашу роботу на основі точки відновлення, що відповідає аварійним ситуаціям.

Ця нова функція підтримується лише для CSI драйверів томів.

Що нового в Beta 2?

Під час тестування бета-версії ми зіткнулися з проблемою, коли поле restoreSize не встановлюється для окремих VolumeSnapshotContents і VolumeSnapshots, якщо драйвер CSI не реалізує виклик RPC ListSnapshots. Ми оцінили різні варіанти тут і вирішили внести цю зміну, випустивши нову бета-версію для API.

Конкретно, у v1beta2 додано структуру VolumeSnapshotInfo, яка містить інформацію про окремий знімок тома, що є членом знімка групи томів. VolumeSnapshotInfoList, список VolumeSnapshotInfo, додано до VolumeGroupSnapshotContentStatus, замінюючи VolumeSnapshotHandlePairList. VolumeSnapshotInfoList — це список інформації про знімки, повернутий драйвером CSI для ідентифікації знімків у системі зберігання. VolumeSnapshotInfoList заповнюється бічним контейнером csi-snapshotter на основі відповіді CSI CreateVolumeGroupSnapshotResponse, поверненої викликом CreateVolumeGroupSnapshot драйвера CSI.

Наявні обʼєкти API v1beta1 будуть перетворені на нові обʼєкти API v1beta2 за допомогою вебхука перетворення.

Що далі?

Залежно від відгуків та впровадження, проєкт Kubernetes планує перенести реалізацію знімків групи томів у загальну доступність (GA) у майбутньому випуску.

Як дізнатися більше?

Дизайн-специфікація для функції знімків групи томів.
Репозиторій коду для API знімків групи томів та контролера.
CSI документація про функцію знімків групи.

Як взяти участь?

Цей проєкт, як і весь Kubernetes, є результатом наполегливої роботи багатьох учасників з різним досвідом, які працюють разом. Від імені SIG Storage я хотів би висловити величезну подяку всім учасникам, які допомогли проєкту досягти бета-версії за останні кілька кварталів:

Ben Swartzlander (bswartz)
Hemant Kumar (gnufied)
Jan Šafránek (jsafrane)
Madhu Rajanna (Madhu-1)
Michelle Au (msau42)
Niels de Vos (nixpanic)
Leonardo Cecchi (leonardoce)
Saad Ali (saad-ali)
Xing Yang (xing-yang)
Yati Padia (yati1998)

Якщо ви зацікавлені взяти участь у проєктуванні та розробці CSI або будь-якої частини системи зберігання Kubernetes, приєднуйтесь до Kubernetes Storage Special Interest Group (SIG). Ми завжди раді новим учасникам.

Ми також проводимо регулярні Data Protection Working Group meetings. Нові учасники завжди можуть приєднатися до наших обговорень.

Kubernetes v1.34: Виділений Taint Manager тепер Stable

Mon, 15 Sep 2025 10:30:00 -0800

Ця функція відокремлює відповідальність за управління життєвим циклом вузлів і виселенням podʼів на два окремі компоненти. Раніше контролер життєвого циклу вузлів обробляв як позначення вузлів як несправних з позначкам (taints) NoExecute, так і виселення podʼів з них. Тепер спеціалізований контролер виселення на основі позначок taint керує процесом, тоді як контролер життєвого циклу вузлів зосереджується виключно на проставлянні taintʼів. Це відокремлення не тільки покращує організацію коду, але й спрощує вдосконалення контролера виселення або створення власних реалізацій виселення на основі позначок.

Що нового?

Функціональна можливість SeparateTaintEvictionController була підвищена до GA в цьому випуску. Користувачі можуть за бажанням вимкнути виселення на основі taintʼів, встановивши --controllers=-taint-eviction-controller в kube-controller-manager.

Як дізнатися більше?

Для отримання додаткової інформації зверніться до KEP та до статті про бета-версію: Kubernetes 1.29: Decoupling taint manager from node lifecycle controller.

Як взяти участь?

Ми висловлюємо величезну подяку всім учасникам, які допомогли з проєктуванням, реалізацією та рецензуванням цієї функції та допомогли перевести її з бета-версії в стабільну:

Ed Bartosh (@bart0sh)
Yuan Chen (@yuanchen8911)
Aldo Culquicondor (@alculquicondor)
Baofa Fan (@carlory)
Sergey Kanzhelev (@SergeyKanzhelev)
Tim Bannister (@lmktfy)
Maciej Skoczeń (@macsko)
Maciej Szulik (@soltysh)
Wojciech Tyczynski (@wojtek-t)

Kubernetes 1.34: Автоконфігурація для драйвера Node Cgroup переходить у стадію загальної доступності (GA)

Fri, 12 Sep 2025 10:30:00 -0800

Історично, налаштування правильного драйвера cgroup було болючою точкою для користувачів, які запускали нові кластери Kubernetes. В системах Linux існують два різні драйвери cgroup: cgroupfs і systemd. У минулому як kubelet, так і реалізація CRI (така як CRI-O або containerd) повинні були бути налаштовані на використання одного й того ж драйвера cgroup, інакше kubelet поводився б неправильно без жодного явного повідомлення про помилку. Це було джерелом головного болю для багатьох адміністраторів кластерів. Тепер ми (майже) поклали край цьому головному болю.

Автоматичне виявлення драйвера cgroup

У v1.28.0 спільнота SIG Node представила функціональну можливість KubeletCgroupDriverFromCRI, яка вказує kubelet запитувати у реалізації CRI, який драйвер cgroup використовувати. Ви можете прочитати більше тут. Після багатьох випусків очікування, поки кожна реалізація CRI випустить основні версії та упакує їх у основні операційні системи, ця функція стала загальнодоступною (GA) з Kubernetes 1.34.0.

На додачу до налаштування функціональної можливості, адміністратори кластерів повинні переконатися, що їх реалізації CRI є достатньо новими:

containerd: Підтримка була додана в v2.0.0
CRI-O: Підтримка була додана в v1.28.0

Оголошення: Kubernetes припиняє підтримку containerd v1.y

Хоча CRI-O випускає версії, які відповідають версіям Kubernetes, і, отже, версії CRI-O без цієї поведінки більше не підтримуються, containerd підтримує свій власний цикл випуску. Підтримка containerd для цієї функції доступна лише в v2.0 і пізніших версіях, але Kubernetes 1.34 все ще підтримує containerd 1.7 та інші LTS випуски containerd.

Спільнота Kubernetes SIG Node формально погодилася на остаточний графік підтримки для containerd v1.y. Останній випуск Kubernetes, який запропонує цю підтримку, буде останньою випущеною версією v1.35, а підтримка буде припинена у v1.36.0. Щоб допомогти адміністраторам у керуванні цією майбутньою трансформацією, доступний новий механізм виявлення. Ви можете моніторити метрику kubelet_cri_losing_support, щоб визначити, чи використовують будь-які вузли у вашому кластері версію containerd, яка незабаром стане застарілою. Наявність цієї метрики з міткою версії 1.36.0 вказуватиме на те, що рушій виконання контейнерів вузла недостатньо новий для майбутніх вимог. Відповідно, адміністратору потрібно буде оновити containerd до v2.0 або пізнішої версії до або одночасно з оновленням kubelet до v1.36.0.

Kubernetes v1.34: Mutable CSI Node Allocatable переходить в Beta

Thu, 11 Sep 2025 10:30:00 -0800

Функція для драйверів CSI, що дозволяє оновлювати інформацію про кількість підключених томів на вузлах, вперше представлена в альфа-версії Kubernetes v1.33, перейшла в бета-версію у випуску Kubernetes v1.34! Це є важливою віхою у підвищенні точності планування podʼівв із збереженням стану шляхом зменшення кількості збоїв, спричинених застарілою інформацією про ємність підключених томів.

Background

Традиційно, CSI драйвери Kubernetes повідомляють про статичний максимальний ліміт підключення томів під час ініціалізації. Однак фактичні ємності підключення можуть змінюватися протягом життєвого циклу вузла з різних причин, таких як:

Ручні або зовнішні операції з підключення/відключення томів поза контролем Kubernetes.
Динамічно підключені мережеві інтерфейси або спеціалізоване обладнання (GPU, NIC тощо), що споживає доступні слоти.
Сценарії з кількома драйверами, коли операції одного драйвера CSI впливають на доступну ємність, про яку повідомляє інший.

Статичне звітування може призвести до того, що Kubernetes запланує поди на вузлах, які, здається, мають ємність, але насправді не мають, що призводить до зависання подів у стані ContainerCreating.

Динамічна адаптація лімітів томів CSI

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

Як це працює

Kubernetes підтримує два механізми для оновлення інформації про ліміти томів вузлів:

Періодичні оновлення: Драйвери CSI вказують інтервал для періодичного оновлення виділеної ємності вузла.
Реактивні оновлення: Негайне оновлення, яке викликається, коли операція підключення тому не вдається через вичерпані ресурси (помилка ResourceExhausted).

Увімкнення функції

Щоб використовувати цю бета-функцію, необхідно увімкнути функціональну можливість MutableCSINodeAllocatableCount в компонентах:

kube-apiserver
kubelet

Приклад конфігурації драйвера CSI

Нижче наведено приклад конфігурації драйвера CSI для увімкнення періодичних оновлень кожні 60 секунд:

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example.csi.k8s.io
spec:
  nodeAllocatableUpdatePeriodSeconds: 60

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

Негайні оновлення при збоях підключення

Коли операція підключення тому не вдається через помилку ResourceExhausted (код gRPC 8), Kubernetes негайно оновлює кількість виділених томів замість того, щоб чекати наступного періодичного оновлення. Kubelet потім позначає постраждалі поди як Failed, що дозволяє їх контролерам відтворити їх. Це запобігає зависанню подів у стані ContainerCreating.

Як почати використовувати

Щоб увімкнути цю функцію у вашому кластері Kubernetes v1.34:

Увімкніть функціональну можливість MutableCSINodeAllocatableCount в компонентах kube-apiserver та kubelet.
Оновіть конфігурацію вашого драйвера CSI, встановивши nodeAllocatableUpdatePeriodSeconds.
Моніторте та спостерігайте за покращеннями в точності планування та надійності розміщення подів.

Наступні кроки

Ця функція наразі знаходиться на стадії бета-тестування, і спільнота Kubernetes вітає ваші відгуки. Тестуйте її, діліться своїм досвідом і допомагайте спрямовувати її еволюцію до стабільності GA.

Приєднуйтесь до обговорень у Kubernetes Storage Special Interest Group (SIG-Storage), щоб сформувати майбутнє можливостей зберігання Kubernetes.

Kubernetes v1.34: Використання контейнера ініціалізації для визначення змінних середовища застосунку

Wed, 10 Sep 2025 10:30:00 -0800

Зазвичай Kubernetes використовує ConfigMaps і Secrets для встановлення змінних середовища, що призводить до додаткових викликів API та складності. Наприклад, вам потрібно окремо керувати Podʼами ваших робочих навантажень і їх конфігураціями, забезпечуючи при цьому впорядковані оновлення як для конфігурацій, так і для Podʼів робочих навантажень.

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

Якщо ви опинилися в такій ситуації, у вас тепер є новий (альфа) спосіб досягти цього. За умови, що у вас увімкнено функціональну можливість EnvFiles у вашому кластері, ви можете вказати kubelet завантажити змінні середовища контейнера з тому (цей том повинен бути частиною Podʼа, до якого належить контейнер). Ця функціональна можливість дозволяє вам завантажувати змінні середовища безпосередньо з файлу з тома emptyDir без фактичного монтування цього файлу в контейнер. Це просте, але елегантне рішення для деяких дивовижно поширених проблем.

Що це все означає?

В основі цієї функціональності лежить можливість вказати контейнеру файл, який генерується initContainer, і дозволити Kubernetes розкласти цей файл на складники для встановлення змінних середовища. Файл розташовується в томі emptyDir (тимчасовому сховищі, яке існує так довго, як існує pod), ваш основний контейнер не потребує монтування тому. Kubelet прочитає файл і впровадить ці змінні, коли контейнер запуститься.

Як це працює

Ось простий приклад:

apiVersion: v1
kind: Pod
spec:
  initContainers:
  - name: generate-config
    image: busybox
    command: ['sh', '-c', 'echo "CONFIG_VAR=HELLO" > /config/config.env']
    volumeMounts:
    - name: config-volume
      mountPath: /config
  containers:
  - name: app-container
    image: gcr.io/distroless/static
    env:
    - name: CONFIG_VAR
      valueFrom:
        fileKeyRef:
          path: config.env
          volumeName: config-volume
          key: CONFIG_VAR
  volumes:
  - name: config-volume
    emptyDir: {}

Використання цього підходу дуже просте. Ви визначаєте свої змінні середовища в специфікації podʼа, використовуючи поле fileKeyRef, яке вказує Kubernetes, де знайти файл і який ключ витягти. Сам файл нагадує стандарт для синтаксису .env (подумайте про KEY=VALUE), і (принаймні у цій альфа-стадії) ви повинні переконатися, що він записується в том emptyDir. Інші типи томів не підтримуються для цієї функції. Принаймні один контейнер ініціалізації повинен змонтувати цей том emptyDir (щоб записати файл), але основний контейнер не потребує цього — він просто отримує змінні, передані йому під час запуску.

Слово про безпеку

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

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

Підсумок

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

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

Tue, 09 Sep 2025 10:30:00 -0800

Роками спільнота 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:

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

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

Як почати

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

Подяки

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

Ahmad Zolfaghari (@ah8ad3)
Ben Luddy (@benluddy) — Red Hat
Chen Chen (@z1cheng) — Microsoft
Davanum Srinivas (@dims) — Nvidia
David Eads (@deads2k) — Red Hat
Han Kang (@logicalhan) — CoreWeave
haosdent (@haosdent) — Shopee
Joe Betz (@jpbetz) — Google
Jordan Liggitt (@liggitt) — Google
Łukasz Szaszkiewicz (@p0lyn0mial) — Red Hat
Maciej Borsz (@mborsz) — Google
Madhav Jivrajani (@MadhavJivrajani) — UIUC
Marek Siarkowicz (@serathius) — Google
NKeert (@NKeert)
Tim Bannister (@lmktfy)
Wei Fu (@fuweid) - Microsoft
Wojtek Tyczyński (@wojtek-t) — Google

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

Kubernetes v1.34: VolumeAttributesClass для зміни атрибутів томів тепер GA

Mon, 08 Sep 2025 10:30:00 -0800

API VolumeAttributesClass, який надає можливість користувачам динамічно змінювати атрибути томів, офіційно перейшов у стадію загальної доступності (GA) у Kubernetes v1.34. Це важлива віхa, яка забезпечує надійний і стабільний спосіб налаштування вашого постійного сховища безпосередньо в Kubernetes.

Що таке VolumeAttributesClass?

По суті, VolumeAttributesClass — це ресурс, що охоплює кластер, який визначає набір змінних параметрів для тому. Розглядайте це як "профіль" для вашого сховища, що дозволяє адміністраторам кластерів експонувати різні рівні якості обслуговування (QoS) або продуктивності.

Користувачі можуть вказати volumeAttributesClassName у своїх PersistentVolumeClaim (PVC), щоб вказати, який клас атрибутів вони бажають. Чарівність відбувається через Container Storage Interface (CSI): коли PVC, що посилається на VolumeAttributesClass, оновлюється, відповідний драйвер CSI взаємодіє з відповідною системою зберігання, щоб застосувати вказані зміни до тому.

Це означає, що ви тепер можете:

Динамічно масштабувати продуктивність: збільшити IOPS або пропускну здатність для завантаженої бази даних або зменшити її для менш критичного застосунку.
Оптимізувати витрати: налаштовувати атрибути на льоту, щоб відповідати вашим поточним потребам, уникаючи надмірного постачання.
Спростити операції: керувати змінами томів безпосередньо в API Kubernetes, а не покладатися на зовнішні інструменти або ручні процеси.

Що нового в GA порівняно з бета

Є два основних вдосконалення порівняно з бета.

Підтримка скасування у разі виникнення помилок

Щоб покращити стійкість і зручність використання, випуск GA вводить явну підтримку скасування, коли під час запиту на зміну тома виникає помилка. Якщо відповідна система зберігання або драйвер CSI вказує, що запитувані зміни не можуть бути застосовані (наприклад, через недійсні аргументи), користувачі можуть скасувати операцію і повернути том до його попередньої стабільної конфігурації, запобігаючи залишенню тому в несумісному стані.

Підтримка квот на основі області дії

Хоча VolumeAttributesClass не додає нового типу квот, панель управління Kubernetes може бути налаштована для примусового дотримання квот на PersistentVolumeClaims, які посилаються на конкретний VolumeAttributesClass.

Це досягається за допомогою поля scopeSelector в ResourceQuota для націлювання на PVC, які мають .spec.volumeAttributesClassName, встановлене на конкретне імʼя VolumeAttributesClass. Будь ласка, дивіться більше деталей тут.

Підтримка драйверами VolumeAttributesClass

Драйвер Amazon EBS CSI: Драйвер AWS EBS CSI має надійну підтримку VolumeAttributesClass і дозволяє динамічно змінювати такі параметри, як тип тому (наприклад, gp2 на gp3, io1 на io2), IOPS і пропускну здатність томів EBS.
Драйвер Google Compute Engine (GCE) Persistent Disk CSI (pd.csi.storage.gke.io): цей драйвер також підтримує динамічну зміну атрибутів постійного диска, включаючи IOPS і пропускну здатність, за допомогою VolumeAttributesClass.

Контакти

Якщо у вас є запитання або конкретні запити, повʼязані з VolumeAttributesClass, будь ласка, звертайтеся до SIG Storage community.

Kubernetes v1.34: Політика заміни Pod для Jobs переходить у GA

Fri, 05 Sep 2025 10:30:00 -0800

В Kubernetes v1.34, функція Політика заміни Pod досягла загальної доступності (GA). Ця стаття описує функцію політики заміни Pod і те, як її використовувати у ваших Jobs.

Про політику заміни Pod

Стандартно контролер Job негайно відтворює Podʼи, як тільки вони виходять з ладу або починають завершувати роботу (коли вони мають мітку часу видалення).

В результаті, хоча деякі Podʼи припиняють роботу, загальна кількість працюючих Podʼів для завдання може тимчасово перевищувати заданий рівень паралельності. Для індексованих Jobs це може навіть означати, що кілька Podʼів працюють для одного й того ж індексу одночасно.

Ця поведінка добре працює для багатьох робочих навантажень, але в певних випадках може викликати проблеми.

Наприклад, популярні фреймворки машинного навчання, такі як TensorFlow та JAX, очікують, що для кожного індексу виконавця буде точно один Pod. Якщо два Podʼа працюють одночасно, ви можете зіткнутися з такими помилками:

/job:worker/task:4: Duplicate task registration with task_name=/job:worker/replica:0/task:4

Крім того, запуск замінних Podʼів до повного завершення старих може призвести до:

Затримок у плануванні з боку kube-scheduler, оскільки вузли залишаються зайнятими.
Непотрібного масштабування кластера для розміщення замінних Podʼів.
Тимчасового обходу перевірок квот з боку оркестраторів робочих навантажень, таких як Kueue.

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

Як працює політика заміни Pod

Це вдосконалення означає, що Jobs у Kubernetes мають необовʼязкове поле .spec.podReplacementPolicy. Ви можете вибрати одну з двох політик:

TerminatingOrFailed (стандартно): Замінює Podʼи, щойно вони починають завершуватися.
Failed: Замінює Podʼи лише після того, як вони повністю завершаться і перейдуть у фазу Failed.

Встановлення політики на Failed забезпечує створення нового Pod лише після повного завершення попереднього.

Для Jobs з політикою відмови Podʼів (Pod Failure Policy), стандартне значення для podReplacementPolicy — Failed, і жодне інше значення не дозволяється. Дивіться Політика відмови Podʼів, щоб дізнатися більше про політики відмови Podʼів для Jobs.

Ви можете перевірити, скільки Podʼів наразі завершуються, перевіривши поле .status.terminating Job:

kubectl get job myjob -o=jsonpath='{.status.terminating}'

Приклад

Ось приклад Job, який виконує завдання двічі (spec.completions: 2) паралельно (spec.parallelism: 2) і замінює Podʼи лише після їх повного завершення (spec.podReplacementPolicy: Failed):

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  completions: 2
  parallelism: 2
  podReplacementPolicy: Failed
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: worker
        image: your-image

Якщо Pod отримує сигнал SIGTERM (видалення, виселення, примусове завершення…), він починає завершувати роботу. Коли контейнер обробляє завершення роботи відповідним чином, очищення може зайняти деякий час.

Коли Job починається, ми побачимо два Podʼа, які працюють:

kubectl get pods

NAME                READY   STATUS    RESTARTS   AGE
example-job-qr8kf   1/1     Running   0          2s
example-job-stvb4   1/1     Running   0          2s

Видалимо один з Podʼів (example-job-qr8kf).

З політикою TerminatingOrFailed, як тільки один Pod (example-job-qr8kf) починає завершуватися, контролер Job негайно створює новий Pod (example-job-b59zk) для його заміни.

kubectl get pods

NAME                READY   STATUS        RESTARTS   AGE
example-job-b59zk   1/1     Running       0          1s
example-job-qr8kf   1/1     Terminating   0          17s
example-job-stvb4   1/1     Running       0          17s

З політикою Failed, новий Pod (example-job-b59zk) не створюється, поки старий Pod (example-job-qr8kf) завершує свою роботу.

kubectl get pods

NAME                READY   STATUS        RESTARTS   AGE
example-job-qr8kf   1/1     Terminating   0          17s
example-job-stvb4   1/1     Running       0          17s

Коли Pod, що завершується, повністю переходить у фазу Failed, створюється новий Pod:

kubectl get pods

NAME                READY   STATUS        RESTARTS   AGE
example-job-b59zk   1/1     Running       0          1s
example-job-stvb4   1/1     Running       0          25s

Як ви можете дізнатися більше?

Ознайомтесь з документацією для користувачів про Політику замини Podʼів, Ліміт затримки для кожного індексу, та Політику відмови Podʼів.
Ознайомтесь з KEP для Політики замини Podʼів, Ліміту затримки для кожного індексу, та Політики відмови Podʼів.

Подяки

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

Оскільки ця функція переходить у стабільний стан після 2 років, ми хотіли б подякувати наступним людям:

Kevin Hannon - за написання KEP та початкову реалізацію.
Michał Woźniak - за керівництво, менторство та рецензії.
Aldo Culquicondor - за керівництво, менторство та рецензії.
Maciej Szulik - за керівництво, менторство та рецензії.
Dejan Zele Pejchev - за те, що взяв на себе цю функцію та просував її з Alpha через Beta до GA.

Долучайтесь

Ця робота була підтримана групою batch working group в тісній співпраці з SIG Apps спільнотою.

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

Метрики PSI для Kubernetes переходять у бета-версію

Thu, 04 Sep 2025 10:30:00 -0800

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

Що таке інформація про затримки (PSI)?

Pressure Stall Information (PSI) є функцією ядра Linux (версія 4.20 і новіші), яка забезпечує канонічний спосіб кількісно оцінити тиск на інфраструктурні ресурси з точки зору того, чи перевищує попит на ресурс поточну пропозицію. Вона виходить за межі простих метрик використання ресурсів і натомість вимірює кількість часу, протягом якого завдання затримуються через конкуренцію за ресурси. Це потужний спосіб виявлення та діагностування вузьких місць у ресурсах, які можуть вплинути на продуктивність застосунків.

PSI надає метрики для CPU, памʼяті та I/O, які класифікуються як some або full pressure:

some: Відсоток часу, протягом якого принаймні одне завдання затримується на ресурсі. Це вказує на певний рівень конкуренції за ресурси.
full: Відсоток часу, протягом якого всі не простоюючі завдання затримуються на ресурсі одночасно. Це вказує на більш серйозне вузьке місце в ресурсах.

PSI: Тиск 'Some' та 'Full'

Ці метрики агрегуються за 10-секундними, 1-хвилинними та 5-хвилинними ковзаючими вікнами, що забезпечує всебічний огляд тиску на ресурси з часом.

Метрики PSI в Kubernetes

З увімкненою функціональною можливістю KubeletPSI, kubelet тепер може збирати метрики PSI з ядра Linux і надавати їх через два канали: Summary API та точку доступу /metrics/cadvisor Prometheus. Це дозволяє вам відстежувати та отримувати сповіщення про тиск на ресурси на рівні вузла, пода та контейнера.

Наступні нові метрики доступні у форматі експозиції Prometheus через /metrics/cadvisor:

container_pressure_cpu_stalled_seconds_total
container_pressure_cpu_waiting_seconds_total
container_pressure_memory_stalled_seconds_total
container_pressure_memory_waiting_seconds_total
container_pressure_io_stalled_seconds_total
container_pressure_io_waiting_seconds_total

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

Виявлення витоків памʼяті: Постійно зростаючий тиск some для памʼяті може вказувати на витік памʼяті в застосунку.
Оптимізація запитів та обмежень ресурсів: Розуміючи тиск на ресурси ваших робочих навантажень, ви можете точніше налаштувати їх запити та обмеження ресурсів.
Автоматичне масштабування робочих навантажень: Ви можете використовувати метрики PSI для ініціювання подій автоматичного масштабування, забезпечуючи, щоб ваші робочі навантаження мали ресурси, необхідні для оптимальної роботи.

Як увімкнути метрики PSI

Щоб увімкнути метрики PSI у вашому кластері Kubernetes, вам потрібно:

Переконатися, що ваші вузли працюють на версії ядра Linux 4.20 або новішій та використовують cgroup v2.
Увімкнути функціональну можливість KubeletPSI у kubelet.

Після увімкнення ви можете почати збирати дані з точки доступу /metrics/cadvisor за допомогою вашого рішення для моніторингу, сумісного з Prometheus, або запитувати Summary API для збору та візуалізації нових метрик PSI. Зверніть увагу, що PSI є функцією ядра Linux, тому ці метрики недоступні на вузлах Windows. Ваш кластер може містити комбінацію вузлів Linux та Windows, але на вузлах Windows kubelet не надає метрики PSI.

Що далі?

Ми раді представити метрики PSI спільноті Kubernetes і чекаємо на ваші відгуки. Як функція бета-версії, ми активно працюємо над поліпшенням і розширенням цієї функціональності до стабільного випуску GA. Ми закликаємо вас спробувати її та поділитися своїм досвідом з нами.

Щоб дізнатися більше про метрики PSI, ознайомтеся з офіційною документацією Kubernetes. Ви також можете долучитися до обговорення на каналі #sig-node в Slack.

Kubernetes v1.34: Інтеграція токенів службових облікових записів для витягування образів контейнерів переходить у стадію бета

Wed, 03 Sep 2025 10:30:00 -0800

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

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

Що нового в бета-версії?

Перехід у бета-версію приносить кілька важливих змін, які роблять цю функцію більш надійною та готовою до промислової експлуатації:

Обовʼязкове поле `cacheType`

Істотна зміна порівняно з альфа-версією: поле cacheType є обовʼязковим у конфігурації постачальника облікових даних під час використання токенів службового облікового запису. Це поле є новим у бета-версії і має бути вказане для забезпечення належного функціонування кешування.

# УВАГА: це не повний приклад конфігурації, а лише посилання на поле 'tokenAttributes.cacheType'.
tokenAttributes:
  serviceAccountTokenAudience: "my-registry-audience"
  cacheType: "ServiceAccount"  # Required field in beta
  requireServiceAccount: true

Обирайте поміж двома стратегіями кешування:

Token: Робіть кешування облікових даних для кожного токена службового облікового запису (використовуйте, коли термін дії облікових даних повʼязаний із токеном). Це корисно, коли постачальник облікових даних перетворює токен службового облікового запису на облікові дані реєстру з таким же терміном дії, як і токен, або коли реєстри безпосередньо підтримують токени службових облікових записів Kubernetes. Примітка: Kubelet не може безпосередньо надсилати токени службових облікових записів до реєстрів; для перетворення токенів у формат імені користувача/пароля, очікуваний реєстрами, потрібні втулки постачальників облікових даних.
ServiceAccount: Кешуйте облікові дані для кожної ідентичності службового облікового запису (використовуйте, коли облікові дані дійсні для всіх подів, які використовують один і той же службовий обліковий запис)

Ізольовані облікові дані для витягування образів

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

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

Адміністратори можуть відкликати доступ до раніше витягнутих образів, видаливши та створивши наново ServiceAccount, що змінює UID і робить недоступним кешований доступ до образів.

Для отримання додаткової інформації про цю можливість дивіться документацію перевірки облікових даних для витягування образів.

Як це працює

Конфігурація

Постачальники облікових даних використовують токени службових облікових записів за допомогою поля tokenAttributes:

#
# УВАГА: це не повний приклад конфігурації, а лише посилання на поле 'tokenAttributes'.
#
apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
providers:
- name: my-credential-provider
  matchImages:
  - "*.myregistry.io/*"
  defaultCacheDuration: "10m"
  apiVersion: credentialprovider.kubelet.k8s.io/v1
  tokenAttributes:
    serviceAccountTokenAudience: "my-registry-audience"
    cacheType: "ServiceAccount"  # New in beta
    requireServiceAccount: true
    requiredServiceAccountAnnotationKeys:
    - "myregistry.io/identity-id"
    optionalServiceAccountAnnotationKeys:
    - "myregistry.io/optional-annotation"

Порядок отримання образів

На високому рівні, kubelet координує свою роботу з постачальником облікових даних та середовищем виконання контейнерів наступним чином:

Коли образ відсутній локально:
- kubelet перевіряє свій кеш облікових даних, використовуючи налаштований cacheType (Token або ServiceAccount)
- Якщо потрібно, kubelet запитує токен ServiceAccount для ServiceAccount пода і передає його, а також будь-які необхідні анотації, постачальнику облікових даних
- Постачальник обмінює цей токен на облікові дані реєстру і повертає їх kubelet
- kubelet кешує облікові дані відповідно до стратегії cacheType і витягує образ з цими обліковими даними
- kubelet записує координати ServiceAccount (простір імен, імʼя, UID) повʼязані з витягнутим образом для подальших перевірок авторизації
Коли образ вже присутній локально:
- kubelet перевіряє координати ServiceAccount пода на відповідність обліковим даним, записаним для кешованого образу
- Якщо вони точно збігаються, можна використовувати кешований образ без витягування з реєстру
- Якщо вони відрізняються, kubelet виконує нове витягування з використанням облікових даних для нового ServiceAccount
З увімкненою перевіркою облікових даних для витягування образів:
- Авторизація виконується з використанням записаних облікових даних ServiceAccount, що забезпечує використання подами лише образів, витягнутих за допомогою ServiceAccount, до яких вони мають право доступу
- Адміністратори можуть відкликати доступ, видаливши та створивши наново ServiceAccount; UID змінюється, і раніше записана авторизація більше не збігається

Обмеження аудиторії

Бета-реліз базується на обмеженнях аудиторії вузлів службових облікових записів (бета з v1.33), щоб забезпечити можливість kubelet запитувати токени лише для авторизованих аудиторій. Адміністратори налаштовують дозволені аудиторії за допомогою RBAC, щоб дозволити kubelet запитувати токени службових облікових записів для витягування образів:

#
# УВАГА: це лише приклад конфігурації.
#          Не використовуйте це для свого кластера!
#
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubelet-credential-provider-audiences
rules:
- verbs: ["request-serviceaccounts-token-audience"]
  apiGroups: [""]
  resources: ["my-registry-audience"]
  resourceNames: ["registry-access-sa"]  # Опціонально: конкретний SA

Початок роботи з бета-версією

Необхідні умови

Kubernetes v1.34 або пізніше
Увімкнено функціональні можливості: KubeletServiceAccountTokenForCredentialProviders=true (бета, стандартно увімкнено)
Підтримка постачальника облікових даних: Update your credential provider to handle ServiceAccount tokens

Міграція з альфа-версії

У випадку, якщо ви вже використовуєте альфа-версію, міграція на бета-версію вимагає мінімальних змін:

Додайте поле cacheType: Оновіть конфігурацію вашого постачальника облікових даних, щоб включити необхідне поле cacheType
Перегляньте стратегію кешування: Виберіть між типами кешу Token і ServiceAccount на основі поведінки вашого постачальника
Перевірте обмеження аудиторії: Переконайтеся, що ваша конфігурація RBAC або інші правила авторизації кластера правильно обмежують аудиторії токенів

Приклад налаштування

Ось повний приклад налаштування постачальника облікових даних з токенами службових облікових записів (цей приклад передбачає, що ваш кластер використовує авторизацію RBAC):

#
# УВАГА: це лише приклад конфігурації.
#          Не використовуйте це для свого кластера!
#

# Service Account з анотаціями реєстру
apiVersion: v1
kind: ServiceAccount
metadata:
  name: registry-access-sa
  namespace: default
  annotations:
    myregistry.io/identity-id: "user123"
---
# RBAC для обмеження аудиторії
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: registry-audience-access
rules:
- verbs: ["request-serviceaccounts-token-audience"]
  apiGroups: [""]
  resources: ["my-registry-audience"]
  resourceNames: ["registry-access-sa"]  # Опціонально: конкретний ServiceAccount
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubelet-registry-audience
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: registry-audience-access
subjects:
- kind: Group
  name: system:nodes
  apiGroup: rbac.authorization.k8s.io
---
# Pod що використовує ServiceAccount
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  serviceAccountName: registry-access-sa
  containers:
  - name: my-app
    image: myregistry.example/my-app:latest

Що далі?

Для Kubernetes v1.35 ми, Kubernetes SIG Auth, очікуємо, що функція залишиться в бета-версії, і ми будемо продовжувати збирати відгуки.

Ви можете дізнатися більше про цю функцію на сторінці токена службового облікового запису для витягування зображень в документації Kubernetes.

Ви також можете стежити за KEP-4412, щоб відстежувати прогрес у майбутніх випусках Kubernetes.

Дійте

У цьому блозі ми висвітлили бета-випуск інтеграції токенів службових облікових записів для Kubelet Credential Providers в Kubernetes v1.34. Ми розглянули ключові поліпшення, включаючи необхідне поле cacheType та вдосконалену інтеграцію з Ensure Secret Pull Images.

Ми отримали позитивні відгуки від спільноти під час альфа-фази і хотіли б почути більше, оскільки ми стабілізуємо цю функцію для GA. Зокрема, ми хотіли б отримати відгуки від розробників постачальників облікових даних під час інтеграції з новим бета-API та механізмами кешування. Будь ласка, звʼяжіться з нами в каналі #sig-auth-authenticators-dev на Kubernetes Slack.

Як взяти участь

Якщо ви зацікавлені в участі в розробці цієї функції, поділіться відгуками або візьміть участь в інших поточних проектах SIG Auth, будь ласка, зв'яжіться з нами в каналі #sig-auth на Kubernetes Slack.

Ви також можете приєднатися до двотижневих зборів SIG Auth, які проходять кожну другу середу.

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

Tue, 02 Sep 2025 10:30:00 -0800

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

Розуміння функції

Що таке кеш uncore?

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

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

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

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

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

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

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

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

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

Стандартно 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. Ця функція імітуватиме ефект розподілу сокетів з найкращими зусиллями та упакує ресурси CPU на сокеті, подібно до стандартної статичної політики менеджера CPU.

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

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

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

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

Долучайтеся

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

Kubernetes v1.34: DRA отримав статус GA

Mon, 01 Sep 2025 10:30:00 -0800

Kubernetes 1.34 вже тут, і він приніс величезну хвилю вдосконалень для Dynamic Resource Allocation (DRA)! Цей реліз знаменує важливу віху: багато API в групі resource.k8s.io отримали статус General Availability (GA), розкриваючи повний потенціал управління пристроями в Kubernetes. Крім того, кілька ключових функцій перейшли до бети, а нова порція альфа-функцій обіцяє ще більше виразності та гнучкості.

Давайте розглянемо, що нового для DRA в Kubernetes 1.34!

Ядро DRA тепер має статус GA

Головною особливістю релізу v1.34 є те, що ядро DRA отримало статус General Availability.

Dynamic Resource Allocation (DRA) у Kubernetes надає гнучкий фреймворк для управління спеціалізованим апаратним та інфраструктурним забезпеченням, таким як GPU або FPGA. DRA надає API, які дозволяють кожному робочому навантаженню вказувати властивості потрібних пристроїв, залишаючи планувальнику завдання розподілу реальних пристроїв, що дозволяє підвищити надійність та покращити використання дорогого обладнання.

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

Починаючи з Kubernetes 1.34, DRA є стандартно увімкненими; функції DRA, які досягли бети, також стандартно увімкнені. Це тому, що стандартною версією API для DRA тепер є стабільна версія v1, а не попередні версії (наприклад: v1beta1 або v1beta2), які потребували явного увімкнення функції.

Функції які, перейшли в бета

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

Позначення мітками адміністративного доступу було оновлено. У v1.34 ви можете обмежити підтримку пристроїв для людей (або застосунків), уповноважених їх використовувати. Це використовується як спосіб уникнути підвищення привілеїв, якщо драйвер DRA надає додаткові привілеї при запиті адміністративного доступу, та уникнути доступу до пристроїв, які використовуються звичайними застосунками, потенційно в іншому просторі імен. Обмеження працює, гарантуючи, що лише користувачі з доступом до простору імен з міткою resource.k8s.io/admin-access: "true" мають право створювати об'єкти ResourceClaim або ResourceClaimTemplates з полем adminAccess, встановленим як true. Це гарантує, що користувачі без прав адміністратора не зможуть зловживати цією функцією.

Список пріоритетів дозволяє користувачам вказувати список прийнятних пристроїв для їхніх робочих навантажень, а не лише один тип пристрою. Тож хоча робоче навантаження може працювати найкраще на одному високопродуктивному GPU, воно також може працювати на 2 GPU середнього рівня. Планувальник спробує задовольнити альтернативи у списку по порядку, тож робоче навантаження отримає найкращий набір доступних пристроїв на вузлі.

API kubelet було оновлено для звітування про ресурси подів, виділені через DRA. Це дозволяє агентам моніторингу вузлів знати про виділені ресурси DRA для подів на вузлі і робить можливим використання інформації DRA в API PodResources для розробки нових функцій та інтеграцій.

Нові альфа-функції

Kubernetes 1.34 також представляє кілька нових альфа-функцій, які дають нам уявлення про майбутнє управління ресурсами з DRA.

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

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

Дивіться Kubernetes v1.34: Споживча ємність DRA для отримання додаткової інформації.

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

Статус справності ресурсу для DRA покращує спостережуваність, показуючи статус справності пристроїв, виділених для пода через Pod Status. Це працює незалежно від того, чи пристрій виділено через DRA чи Device Plugin. Це полегшує розуміння причини несправного стану пристрою та відповідне реагування.

Дивіться Kubernetes v1.34: Звіт про стан ресурсів DRA в Podʼах для отримання додаткової інформації.

Що далі?

Хоча DRA отримав статус GA в цьому циклі, наполеглива робота над DRA не припиняється. Є кілька функцій в альфа та бета статусі, які ми плануємо довести до GA в наступних кількох релізах, і ми прагнемо продовжувати покращувати продуктивність, масштабованість та надійність DRA. Тож очікуйте такий же амбітний набір функцій в DRA для релізу 1.35.

Як долучитися

Хорошою відправною точкою є приєднання до Slack-каналу WG Device Management та зустрічей, які відбуваються у зручний для US/EU та EU/APAC час.

Не всі ідеї щодо вдосконалень ще відстежуються як issues, тож приходьте поговорити з нами, якщо хочете допомогти або маєте власні ідеї! У нас є робота на всіх рівнях, від складних основних змін до покращень зручності використання в kubectl, які могли б бути підхоплені новачками.

Подяки

Величезна подяка новим учасникам DRA цього циклу:

Alay Patel (alaypatel07)
Gaurav Kumar Ghildiyal (gauravkghildiyal)
JP (Jpsassine)
Kobayashi Daisuke (KobayashiD27)
Laura Lorenz (lauralorenz)
Sunyanan Choochotkaew (sunya-ch)
Swati Gupta (guptaNswati)
Yu Liao (yliaog)

Kubernetes v1.34: Більш точний контроль над перезапуском контейнерів

Fri, 29 Aug 2025 10:30:00 -0800

З виходом Kubernetes 1.34, було представлено нову альфа-функцію, яка надає більш детальний контроль над перезапусками контейнерів у межах Pod. Ця функція, названа Container Restart Policy and Rules, дозволяє вам вказати політику перезапуску для кожного контейнера окремо, перевизначаючи глобальну політику перезапуску Podʼа. Крім того, вона також дозволяє перезапускати окремі контейнери на основі їх кодів виходу. Ця функція доступна за альфа-функціональною можливістю ContainerRestartRules.

Ця функція була давно очікуваною. Розглянемо, як вона працює і як ви можете її використовувати.

Проблема з єдиною політикою перезапуску

До цієї функції restartPolicy встановлювалася на рівні Podʼа. Це означало, що всі контейнери в Podʼі ділили одну й ту ж політику перезапуску (Always, OnFailure або Never). Хоча це підходить для багатьох випадків використання, в інших ситуаціях це може бути обмеженням.

Наприклад, розглянемо Pod з основним контейнером застосунку та ініціалізаційним контейнером, який виконує деякі початкові налаштування. Ви можете захотіти, щоб основний контейнер завжди перезапускався у разі збою, але ініціалізаційний контейнер повинен виконуватися лише один раз і ніколи не перезапускатися. З єдиною політикою перезапуску на рівні Pod це було неможливо.

Введення політик перезапуску для кожного контейнера

З новою функцією ContainerRestartRules ви тепер можете вказати restartPolicy для кожного контейнера в специфікації вашого Podʼа. Ви також можете визначити restartPolicyRules, щоб контролювати перезапуски на основі кодів виходу. Це дає вам детальний контроль, необхідний для обробки складних сценаріїв.

Варіанти використання

Давайте розглянемо деякі реальні випадки використання, де політики перезапуску для кожного контейнера можуть бути корисними.

Перезапуски на місці для завдань навчання моделей

У дослідженнях машинного навчання часто потрібно організовувати велику кількість тривалих навчальних навантажень AI/ML. У цих сценаріях збої навантаження є неминучими. Коли навантаження зазнає збою з кодом виходу, що підлягає повторному виконанню, ви хочете, щоб контейнер швидко перезапускався без повторного планування всього Podʼа, що споживає значну кількість часу та ресурсів. Перезапуск невдалого контейнера "на місці" є критично важливим для кращого використання обчислювальних ресурсів. Контейнер повинен перезапускатися "на місці" лише у разі збою через помилку, що підлягає повторному виконанню; в іншому випадку контейнер і Pod повинні завершити роботу та, можливо, бути повторно запланованими.

Це тепер можна досягти за допомогою правил restartPolicyRules на рівні контейнера. Навантаження може завершитися з різними кодами, щоб представити помилки, що підлягають повторному виконанню, і непідлягають повторному виконанню. Завдяки restartPolicyRules навантаження може бути швидко перезапущено на місці, але лише тоді, коли помилка підлягає повторному виконанню.

Ініціалізаційні контейнери з одноразовим виконанням

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

З політикою перезапуску на рівні контейнера це тепер можливо. Ініціалізаційний контейнер може виконуватися лише один раз, і його збій буде вважатися збоєм Podʼа. Якщо ініціалізація проходить успішно, основний контейнер завжди може бути перезапущений.

Podʼи з кількома контейнерами

Для Podʼів, які виконують кілька контейнерів, ви можете мати різні вимоги до перезапуску для кожного контейнера. Деякі контейнери можуть мати чітке визначення успіху і повинні перезапускатися лише у разі збою. Інші можуть потребувати постійного перезапуску.

Це тепер можливо з політикою перезапуску на рівні контейнера, що дозволяє окремим контейнерам мати різні політики перезапуску.

Як це використовувати

Щоб використовувати цю нову функцію, вам потрібно увімкнути функціональну можливість ContainerRestartRules в панелі управління вашого кластера Kubernetes та робочих вузлах, які працюють на Kubernetes 1.34+. Після увімкнення ви можете вказати поля restartPolicy та restartPolicyRules у визначеннях ваших контейнерів.

Ось кілька прикладів:

Приклад 1: Перезапуск на основі конкретних кодів виходу

У цьому прикладі контейнер повинен перезапуститися, якщо і тільки якщо він зазнає збою з помилкою, що підлягає повторному виконанню, що представляється кодом виходу 42.

Щоб досягти цього, контейнер має restartPolicy: Never, і правило політики перезапуску, яке вказує Kubernetes перезапустити контейнер на місці, якщо він завершується з кодом 42.

apiVersion: v1
kind: Pod
metadata:
  name: restart-on-exit-codes
  annotations:
    kubernetes.io/description: "This Pod only restart the container only when it exits with code 42."
spec:
  restartPolicy: Never
  containers:
  - name: restart-on-exit-codes
    image: docker.io/library/busybox:1.28
    command: ['sh', '-c', 'sleep 60 && exit 0']
    restartPolicy: Never     # Політика перезапуску контейнера повинна бути вказана, якщо правила вказані
    restartPolicyRules:      # Тільки перезапустити контейнер, якщо він завершується з кодом 42
    - action: Restart
      exitCodes:
        operator: In
        values: [42]

Приклад 2: Ініціалізаційний контейнер з одною спробою запуску

У цьому прикладі Pod повинен завжди перезапускатися після успішної ініціалізації. Однак ініціалізація повинна бути спробована лише один раз.

Щоб досягти цього, Pod має політику перезапуску Always. Ініціалізаційний контейнер init-once спробує запуститися лише один раз. Якщо він зазнає невдачі, Pod зазнає невдачі. Це дозволяє Pod зазнати невдачі, якщо ініціалізація не вдалася, але також продовжувати працювати, як тільки ініціалізація буде успішною.

apiVersion: v1
kind: Pod
metadata:
  name: fail-pod-if-init-fails
  annotations:
    kubernetes.io/description: "This Pod has an init container that runs only once. After initialization succeeds, the main container will always be restarted."
spec:
  restartPolicy: Always
  initContainers:
  - name: init-once      # Цей контейнер ініціалізації спробує запуститись лише один раз. Якщо спроба не вдасться, Pod не працюватиме.
    image: docker.io/library/busybox:1.28
    command: ['sh', '-c', 'echo "Failing initialization" && sleep 10 && exit 1']
    restartPolicy: Never
  containers:
  - name: main-container # Цей контейнер завжди буде перезапущений, як тільки ініціалізація буде успішною.
    image: docker.io/library/busybox:1.28
    command: ['sh', '-c', 'sleep 1800 && exit 0']

Приклад 3: Контейнери з різними політиками перезапуску

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

Це досягається за допомогою різних політик перезапуску на рівні контейнера для кожного з двох контейнерів.

apiVersion: v1
kind: Pod
metadata:
  name: on-failure-pod
  annotations:
    kubernetes.io/description: "This Pod has two containers with different restart policies."
spec:
  containers:
  - name: restart-on-failure
    image: docker.io/library/busybox:1.28
    command: ['sh', '-c', 'echo "Not restarting after success" && sleep 10 && exit 0']
    restartPolicy: OnFailure
  - name: restart-always
    image: docker.io/library/busybox:1.28
    command: ['sh', '-c', 'echo "Always restarting" && sleep 1800 && exit 0']
    restartPolicy: Always

Дізнайтеся більше

Ознайомтеся з документацією про політику перезапуску контейнерів.
Ознайомтеся з KEP для правил перезапуску контейнерів

Плани

Більше дій та сигналів для перезапуску Pod і контейнерів зʼявляться незабаром! Зокрема, планується додати підтримку перезапуску всього Podʼа. Планування та обговорення цих функцій тривають. Не соромтеся ділитися відгуками або запитами до спільноти SIG Node!

Ми будемо раді отримати ваші відгуки!

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

Ви можете звʼязатися з SIG Node кількома способами:

Kubernetes v1.34: Налаштування користувача (kuberc) доступні для тестування в kubectl 1.34

Thu, 28 Aug 2025 10:30:00 -0800

Чи хотіли ви будь-коли, щоб ви могли мати стандартно увімкнене інтерактивне видалення у kubectl? Або, можливо, ви хочете визначити власні псевдоніми, але не обовʼязково генерувати сотні з них вручну? Шукайте далі. SIG-CLI наполегливо працює над додаванням налаштувань користувача до kubectl, і ми раді оголосити, що ця функціональність досягає бета-версії в рамках випуску Kubernetes v1.34.

Як це працює

Повний опис цієї функціональності доступний в нашій офіційній документації, але в цьому дописі ми відповімо на обидва питання з початку цієї статті.

Перед тим, як зануритися в деталі, давайте швидко розглянемо, як виглядає файл налаштувань користувача та де його розмістити. Типово kubectl буде шукати файл kuberc у вашій стандартній теці kubeconfig, яка знаходиться за адресою $HOME/.kube. Альтернативно, ви можете вказати це місце за допомогою параметра --kuberc або змінної середовища KUBERC.

Як і кожен маніфест Kubernetes, файл kuberc почнеться з apiVersion та kind:

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
# тут будуть відображатися налаштування користувача

Defaults

Почнемо з налаштування стандартних значень для параметрів команд kubectl. Наша мета — завжди використовувати інтерактивне видалення, що означає, що ми хочемо, щоб параметр --interactive для kubectl delete завжди був встановлений на true. Це можна досягти, додавши наступний фрагмент до нашого файлу kuberc:

defaults:
- command: delete
  options:
  - name: interactive
    default: "true"

В цьому прикладі ми представляємо секцію defaults, яка дозволяє користувачам визначати стандартні значення для параметрів kubectl. У цьому випадку ми встановлюємо параметр інтерактивності для kubectl delete на true. Це значення можна перевизначити, якщо користувач явно надає інше значення, наприклад, kubectl delete --interactive=false, в цьому випадку явний параметр має пріоритет.

Ще одне дуже рекомендоване типове значення від SIG-CLI — це використання Server-Side Apply. Щоб це зробити, ви можете додати наступний фрагмент до ваших налаштувань:

# продовження розділу defaults
- command: apply
  options:
  - name: server-side
    default: "true"

Aliases

Можливість визначати аліаси дозволяє нам заощаджувати дорогоцінні секунди під час введення команд. Я впевнений, що ви, напевно, маєте один визначений для kubectl, оскільки введення семи літер безумовно займає більше часу, ніж просто натискання k.

З цієї причини можливість визначати аліаси була обовʼязковою, коли ми вирішили реалізувати налаштування користувача, поряд з установкою стандартних значень. Щоб визначити аліас для будь-якої з вбудованих команд, розширте свій файл kuberc наступним:

aliases:
- name: gns
  command: get
  prependArgs:
   - namespace
  options:
   - name: output
     default: json

Там багато чого відбувається, тому давайте розберемо це по черзі. По-перше, ми вводимо новий розділ: aliases. Тут ми визначаємо новий аліас gns, який відображається на команду get. Далі ми визначаємо аргументи (namespace ресурс), які будуть вставлені відразу після назви команди. Крім того, ми встановлюємо опцію --output=json для цього аліаса. Структура блоку options ідентична тій, що в розділі defaults.

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

# продовження розділу aliases
- name: runx
  command: run
  options:
    - name: image
      default: busybox
    - name: namespace
      default: test-ns
  appendArgs:
    - --
    - custom-arg

Тут ми вводимо ще один аліас: runx, який викликає команду kubectl run, передаючи параметри --image і --namespace з попередньо визначеними значеннями, а також додаючи -- і custom-arg в кінці виклику.

Відлагодження

Ми сподіваємося, що налаштування користувача kubectl відкриє нові можливості для наших користувачів. Коли у вас виникають сумніви, не соромтеся запускати kubectl з підвищеною докладністю виводу. При -v=5 ви повинні отримати всю можливу інформацію для відлагодження з цієї функції, що буде важливо при повідомленні про проблеми.

Щоб дізнатися більше, я закликаю вас ознайомитися з нашою офіційною документацією та фактичною пропозицією.

Долучайтесь

Функція налаштувань користувача Kubectl досягла бета-версії, і ми дуже зацікавлені у ваших відгуках. Нам хотілося б почути, що вам подобається в ній і які проблеми ви хотіли б вирішити. Не соромтеся приєднуватися до каналу SIG-CLI slack, або відкривати тікети в репозиторії kubectl. Ви також можете приєднатися до наших зустрічей спільноти, які відбуваються кожну другу середу, і поділитися своїми історіями з нами.

Kubernetes v1.34: Of Wind & Will (O' WaW)

Wed, 27 Aug 2025 10:30:00 -0800

Редактори: Agustina Barbetta, Alejandro Josue Leon Bellido, Graziano Casto, Melony Qin, Dipesh Rawat

Подібно до попередніх релізів, випуск Kubernetes v1.34 представляє нові стабільні, бета- та альфа-функції. Послідовне надання високоякісних релізів підкреслює силу нашого циклу розробки та активну підтримку нашої спільноти.

Цей реліз складається з 58 покращень. З них 23 перейшли до стабільного стану, 22 входять до бета-версії, а 13 перейшли до альфа-версії.

У цьому релізі також є застарівання та видалення функцій; обовʼязково ознайомтеся з ними.

Тема та логотип релізу

Випуск, що рухається силою вітру навколо нас — і силою нашої волі.

Кожен цикл випуску ми успадковуємо вітри, які насправді не контролюємо — стан наших інструментів, документації та історичні особливості нашого проєкту. Іноді ці вітри наповнюють наші вітрила, іноді вони штовхають нас убік або стихають.

Те, що тримає Kubernetes в русі, не ідеальні вітри, а воля наших моряків, які регулюють вітрила, тримають штурвал, прокладають курси і тримають корабель на плаву. Випуск відбувається не тому, що умови завжди ідеальні, а завдяки людям, які його створюють, людям, які його випускають, і ведмедям^{^}, котам, собакам, чарівникам і допитливим умам, які допомагають Kubernetes залишатися на плаву — незалежно від того, в якому напрямку дме вітер.

Цей реліз, Of Wind & Will (O' WaW), вшановує вітри, які сформували нас, і волю, яка штовхає нас вперед.

_{^ О, і ви здивовані, чому ведмеді? Продовжуйте дивуватися!}

Основні оновлення

Kubernetes v1.34 насичений новими функціями та покращеннями. Ось кілька оновлень, які команда випуску хотіла б виділити!

Stable: Ядро DRA тепер GA

Динамічне виділення ресурсів (DRA) дозволяє використовувати потужніші способи вибору, виділення, спільного використання та налаштування GPU, TPU, мережевих карт та інших пристроїв.

Починаючи з релізу v1.30, DRA базується на заявках на пристрої за допомогою структурованих параметрів, які є непрозорими для ядра Kubernetes. Це покращення було натхненне динамічним провізуванням для сховищ. DRA зі структурованими параметрами спирається на набір допоміжних API-видів: ResourceClaim, DeviceClass, ResourceClaimTemplate та ResourceSlice API-типів в рамках resource.k8s.io, одночасно розширюючи .spec для Podʼів новим полем resourceClaims. API resource.k8s.io/v1 стали стабільними і тепер є стандартно доступними.

Ця робота була виконана в рамках KEP #4381, очолюваної WG Device Management.

Beta: Захищені токени ServiceAccount для провайдерів облікових даних образів `kubelet`

Постачальники облікових даних kubelet, які використовуються для отримання приватних контейнерних образів, традиційно покладалися на довгострокові Secrets, збережені на вузлі або в кластері. Такий підхід збільшував ризики безпеки та ускладнював управління, оскільки ці облікові дані не були привʼязані до конкретного робочого навантаження і не оновлювалися автоматично. Щоб вирішити цю проблему, kubelet тепер може запитувати короткочасні, привʼязані до певної аудиторії токени ServiceAccount для автентифікації в контейнерних реєстрах. Це дозволяє авторизувати отримання образів на основі власної ідентичності Podʼа, а не облікових даних на рівні вузла. Основна перевага полягає в значному поліпшенні безпеки. Це усуває необхідність у довгострокових Secrets для отримання образів, зменшуючи поверхню атаки та спрощуючи управління обліковими даними як для адміністраторів, так і для розробників.

Ця робота була виконана в рамках KEP #4412, очолюваної SIG Auth та SIG Node.

Alpha: Підтримка KYAML, діалекту YAML для Kubernetes

KYAML має бути більш безпечним і менш неоднозначною підмножиною YAML, і був спроектований спеціально для Kubernetes. Незалежно від версії Kubernetes, яку ви використовуєте, починаючи з Kubernetes v1.34 ви можете використовувати KYAML як новий формат виводу для kubectl.

KYAML вирішує специфічні проблеми як з YAML, так і з JSON. Значний пробіл YAML вимагає уважної уваги до відступів та вкладеності, тоді як необовʼязкове взяття рядків в лапки може призвести до неочікуваного приведення типів (наприклад: "The Norway Bug"). Тим часом, JSON не підтримує коментарі та має суворі вимоги до наявності ком та ключів в лапках.

Ви можете писати KYAML та передавати його як вхідні дані будь-якій версії kubectl, оскільки всі файли KYAML також є дійсними YAML. З kubectl v1.34 ви також можете запитувати вивід у форматі KYAML (як у kubectl get -o kyaml …), встановивши змінну середовища KUBECTL_KYAML=true. Якщо ви бажаєте, ви все ще можете запитувати вивід у форматі JSON або YAML.

Ця робота була виконана в рамках KEP #5295, очолюваної SIG CLI.

Функції, що переходять у стабільний стан

Це вибір деяких покращень, які тепер є стабільними після випуску v1.34.

Відкладене створення замінних Podʼів для Job

Стандартно, контролери Job створюють замінні Podʼи негайно, коли Pod починає завершення своєї роботи, що призводить до одночасного виконання обох Podʼів. Це може спричинити конкуренцію за ресурси в обмежених кластерах, де замінний Pod може зіткнутися з труднощами при пошуку доступних вузлів, поки оригінальний Pod повністю не завершиться. Ситуація також може спровокувати небажане збільшення масштабу кластеру. Крім того, деякі фреймворки машинного навчання, такі як TensorFlow та JAX, вимагають, щоб на індекс припадав лише один Pod, що робить одночасне виконання Podʼів проблематичним. Ця функція вводить .spec.podReplacementPolicy у Jobs. Ви можете вибрати створення замінних Podʼів лише тоді, коли Pod повністю завершено (має .status.phase: Failed). Для цього встановіть .spec.podReplacementPolicy: Failed. Представлена як альфа у v1.28, ця функція стала стабільною у v1.34.

Ця робота була виконана в рамках KEP #3939, очолюваної SIG Apps.

Відновлення після збою розширення тому

Ця функція дозволяє користувачам скасовувати розширення тому, які не підтримуються підляглими постачальниками зберігання, і повторно спробувати розширити том з меншими значеннями, які можуть бути успішними. Представлена як альфа у v1.23, ця функція стала стабільною у v1.34.

Ця робота була виконана в рамках KEP #1790, очолюваної SIG Storage.

VolumeAttributesClass для зміни томів

VolumeAttributesClass став стабільним у v1.34. VolumeAttributesClass — це загальний, рідний для Kubernetes API для зміни параметрів тому, таких як виділений IO. Він дозволяє робочим навантаженням вертикально масштабувати свої томи онлайн для балансування вартості та продуктивності, якщо це підтримується їх провайдером. Як і всі нові функції томів в Kubernetes, цей API реалізується через інтерфейс зберігання контейнерів (CSI). Ваш специфічний для провайдерів CSI драйвер повинен підтримувати новий ModifyVolume API, який є CSI стороною цієї функції.

Ця робота була виконана в рамках KEP #3751, очолюваної SIG Storage.

Структурована конфігурація автентифікації

Kubernetes v1.29 представив формат файлу конфігурації для управління автентифікацією клієнта API сервера, відмовившись від попередньої залежності від великої кількості параметрів командного рядка. AuthenticationConfiguration дозволяє адміністраторам підтримувати кілька автентифікаторів JWT, перевірку виразів CEL та динамічну перезагрузку. Ця зміна суттєво покращує керованість та можливість аудиту налаштувань автентифікації кластеру, і стала стабільною у v1.34.

Ця робота була виконана в рамках KEP #3331, очолюваної SIG Auth.

Більш детальна авторизація на основі селекторів

Авторизатори Kubernetes, включаючи веб-хуки авторизації та вбудований авторизатор вузлів, тепер можуть приймати рішення про авторизацію на основі селекторів полів та міток у вхідних запитах. Коли ви надсилаєте запити list, watch або deletecollection з селекторами, шар авторизації тепер може оцінювати доступ з урахуванням цього додаткового контексту.

Наприклад, ви можете написати політику авторизації, яка дозволяє лише вивід переліку Podʼів, привʼязаних до конкретного .spec.nodeName. Клієнт (можливо, kubelet на певному вузлі) повинен вказати селектор поля, який вимагає політика, в іншому випадку запит заборонено. Ця зміна робить можливим налаштування правил найменшого привілею, за умови, що клієнт знає, як відповідати встановленим вами обмеженням. Kubernetes v1.34 тепер підтримує більш детальний контроль у таких середовищах, як ізоляція на рівні вузлів або спеціальні багатокористувацькі налаштування.

Ця робота була виконана в рамках KEP #4601, очолюваної SIG Auth.

Обмеження анонімних запитів за допомогою детальних налаштувань контролю

Замість повного увімкнення або вимкнення анонімного доступу, ви тепер можете налаштувати суворий список точок доступу, де дозволені неавтентифіковані запити. Це забезпечує більш безпечну альтернативу для кластерів, які покладаються на анонімний доступ до точок доступу, таких як /healthz, /readyz або /livez.

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

Ця робота була виконана в рамках KEP #4633, очолюваної SIG Auth.

Більш ефективне повторне додавання в чергу за допомогою зворотних викликів, специфічних для відповідних втулків

kube-scheduler тепер може приймати більш точні рішення про те, коли повторно намагатися запланувати Podʼи, які раніше не вдалося запланувати. Кожен втулок планування тепер може реєструвати функції зворотного виклику, які повідомляють планувальнику, чи ймовірно, що вхідна подія кластера знову зробить Pod, що відхиляється, придатним для планування.

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

Ця робота була виконана в рамках KEP #4247, очолюваної SIG Scheduling.

Впорядковане видалення Namespace

Напіввипадковий порядок видалення ресурсів може створювати прогалини в безпеці або непередбачувану поведінку, таку як збереження Podʼів після видалення їх асоційованих NetworkPolicies. Це покращення впроваджує більш структурований процес видалення для просторів імен Kubernetes, щоб забезпечити безпечне та детерміноване видалення ресурсів. Дотримуючись структурованої послідовності видалення, яка враховує логічні та безпекові залежності, цей підхід забезпечує видалення Podʼів перед іншими ресурсами. Ця функція була представлена в Kubernetes v1.33 і стала стабільною в v1.34. Підвищення безпеки та надійності завдяки зменшенню ризиків від недетермінованих видалень, включаючи вразливість, описану в CVE-2024-7598.

Ця робота була виконана в рамках KEP #5080, очолюваної SIG API Machinery.

Потокове передавання list відповідей

Обробка великих list відповідей у Kubernetes раніше становила значну проблему масштабованості. Коли клієнти запитували великі списки ресурсів, такі як тисячі Podʼів або Custom Resources, API серверу потрібно було серіалізувати всю колекцію обʼєктів в один великий буфер памʼяті перед відправленням. Цей процес створював значний тиск на памʼять і міг призвести до погіршення продуктивності, впливаючи на загальну стабільність кластера. Щоб розвʼязати це обмеження, було впроваджено механізм кодування потоків для колекцій (відповідей списку). Цей механізм потокового передавання автоматично активний для форматів відповіді JSON та Kubernetes Protobuf, і відповідна функціональна можливість є стабільною. Основна перевага цього підходу полягає в уникненні великих алокацій памʼяті на API сервері, що призводить до набагато меншої та більш передбачуваної витрати памʼяті. Внаслідок цього кластер стає більш стійким і продуктивним, особливо в середовищах великого масштабу, де часті запити на великі списки ресурсів є звичайними.

Ця робота була виконана в рамках KEP #5116, очолюваної SIG API Machinery.

Ініціалізація стійкого кешу спостереження

Watch cache — це шар кешування всередині kube-apiserver, який підтримує врешті-решт узгоджений кеш стану кластера, збереженого в etcd. У минулому могли виникати проблеми, коли кеш спостереження ще не був ініціалізований під час запуску kube-apiserver або коли він вимагав повторної ініціалізації.

Щоб вирішити ці проблеми, процес ініціалізації кешу спостереження став більш стійким до збоїв, покращуючи надійність панелі управління та забезпечуючи надійне встановлення спостережень для контролерів і клієнтів. Це покращення було представлено як бета у v1.31 і тепер є стабільним.

Ця робота була виконана в рамках KEP #4568, очолюваної SIG API Machinery та SIG Scalability.

Послаблення перевірки шляху пошуку DNS

Раніше сувора перевірка шляху DNS search у Kubernetes часто створювала проблеми інтеграції в складних або застарілих мережевих середовищах. Ця обмеженість могла блокувати конфігурації, які були необхідні для інфраструктури організації, змушуючи адміністраторів впроваджувати складні обхідні шляхи. Щоб вирішити цю проблему, була введена послаблена перевірка DNS як альфа у v1.32, і вона стала стабільною у v1.34. Загальний випадок використання включає Podʼи, які повинні спілкуватися як з внутрішніми службами Kubernetes, так і з зовнішніми доменами. Встановивши одну крапку (.) як перший запис у списку searches поля .spec.dnsConfig Pod, адміністратори можуть запобігти додаванню внутрішніх доменів пошуку кластера до зовнішніх запитів. Це запобігає створенню непотрібних DNS-запитів до внутрішнього DNS-сервера для зовнішніх імен хостів, покращуючи ефективність та запобігаючи потенційним помилкам резолюції.

Ця робота була виконана в рамках KEP #4427, очолюваної SIG Network.

Підтримкадля Direct Service Return (DSR) у Windows `kube-proxy`

DSR забезпечує оптимізацію продуктивності, дозволяючи поверненню трафіку, що маршрутизується через балансувальники навантаження, обходити балансувальник і безпосередньо відповідати клієнту, зменшуючи навантаження на балансувальник і покращуючи загальну затримку. Для отримання інформації про DSR у Windows читайте Direct Server Return (DSR) in a nutshell. Спочатку представлена у v1.14, ця функція стала стабільною у v1.34.

Ця робота була виконана в рамках KEP #5100, очолюваної SIG Windows.

Дія Sleep для хуків життєвого циклу контейнерів

Дія Sleep для хуків життєвого циклу контейнерів PreStop і PostStart була введена, щоб забезпечити простий спосіб керування процесом відповідного завершення роботи та покращити загальне управління життєвим циклом контейнерів. Дія Sleep дозволяє контейнерам призупинятися на вказаний період після запуску або перед завершенням. Використання негативної або нульової тривалості сну призводить до негайного повернення, що призводить до відсутності операції. Дія Sleep була представлена в Kubernetes v1.29, з підтримкою нульового значення, доданою в v1.32. Обидві функції стали стабільними в v1.34.

Ця робота була виконана в рамках KEP #3960 та KEP #4818, очолюваної SIG Node.

Підтримка свопу на вузлах Linux

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

Щоб вирішити цю проблему, підтримка свопу з налаштуваннями на рівні вузлів була представлена у v1.22. Вона пройшла через альфа- та бета-етапи і стала стабільною у v1.34. Основний режим, LimitedSwap, дозволяє Podʼам використовувати своп всередині їх наявних обмежень памʼяті, надаючи безпосереднє розвʼязання проблеми. Стандартно, kubelet налаштований у режимі NoSwap, що означає, що робочі навантаження Kubernetes не можуть використовувати своп.

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

Ця робота була виконана в рамках KEP #2400, очолюваної SIG Node.

Дозвіл на використання спеціальних символів в змінних середовища

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

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

Ця робота була виконана в рамках KEP #4369, очолюваної SIG Node.

Керування позначками taint тепер відокремлено від життєвого циклу вузлів

Історично, логіка TaintManager щодо застосування taints NoSchedule та NoExecute до вузлів на основі їх стану (NotReady, Unreachable тощо) була тісно повʼязана з контролером життєвого циклу вузлів. Це тісне зʼєднання ускладнювало обслуговування та тестування коду, а також обмежувало гнучкість механізму виселення на основі taint. Цей KEP переносить TaintManager у свій власний окремий контролер у межах менеджера контролерів Kubernetes. Це внутрішнє архітектурне покращення, спрямоване на підвищення модульності та підтримуваності коду. Ця зміна дозволяє логіці виселення на основі taint тестуватися та розвиватися незалежно, але не має прямого впливу на користувацький інтерфейс щодо використання taints.

Ця робота була виконана в рамках KEP #3902, очолюваної SIG Scheduling та SIG Node.

Нові Beta функції

Це деякі покращення, які тепер є бета після випуску v1.34.

Запити та обмеження ресурсів на рівні Pod

Визначення потреб у ресурсах для Podʼів з кількома контейнерами було складним, оскільки запити та обмеження могли бути встановлені лише на рівні кожного контейнера. Це змушувало розробників або перевищувати виділені ресурси для кожного контейнера, або ретельно ділити загальні бажані ресурси, ускладнюючи конфігурацію та часто призводячи до неефективного виділення ресурсів. Щоб спростити це, була введена можливість вказувати запити та обмеження ресурсів на рівні Podʼів. Це дозволяє розробникам визначати загальний бюджет ресурсів для Podʼа, який потім ділиться між його контейнерами. Ця функція була представлена як альфа у v1.32 і стала бета у v1.34, при цьому HPA тепер підтримує специфікації ресурсів на рівні подів.

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

Ця робота була виконана в рамках KEP #2837, очолюваної SIG Scheduling та SIG Autoscaling.

Файл `.kuberc` для налаштувань користувача `kubectl`

Файл конфігурації .kuberc дозволяє визначити уподобання для kubectl, такі як стандартні параметри та псевдоніми команд. На відміну від файлу kubeconfig, файл конфігурації .kuberc не містить інформації про кластер, імен користувачів або паролів. Ця функція була представлена як альфа у v1.33, під контролем змінної середовища KUBECTL_KUBERC. Вона стала бета у v1.34 і є стандартно увімкненою.

Ця робота була виконана в рамках KEP #3104, очолюваної SIG CLI.

Підписування токенів зовнішніх ServiceAccount

Традиційно, Kubernetes управляє токенами ServiceAccount, використовуючи статичні ключі підпису, які завантажуються з диска під час запуску kube-apiserver. Ця функція впроваджує сервіс gRPC ExternalJWTSigner для підпису поза процесом, що дозволяє дистрибутивам Kubernetes інтегруватися з зовнішніми рішеннями для управління ключами (наприклад, HSM, хмарні KMS) для підпису токенів ServiceAccount замість статичних ключів на диску.

Представлена як альфа у v1.32, ця зовнішня можливість підпису JWT переходить у бета-версію та є стандартно увімкненою у v1.34.

Ця робота була виконана в рамках KEP #740, очолюваної SIG Auth.

Функції DRA у бета-версії

Адміністративний доступ для безпечного моніторингу ресурсів

DRA підтримує контрольований адміністративний доступ через поле adminAccess у ResourceClaims або ResourceClaimTemplates, що дозволяє операторам кластерів отримувати доступ до пристроїв, які вже використовуються іншими, для моніторингу або діагностики. Цей привілейований режим обмежений користувачами, уповноваженими створювати такі обʼєкти в просторах імен, помічених як resource.k8s.io/admin-access: "true", що забезпечує, щоб звичайні робочі навантаження залишалися неушкодженими. Перехід до бета-версії у v1.34 надає цю функцію безпечних інструментів для спостереження, зберігаючи при цьому ізоляцію робочих навантажень через авторизаційні перевірки на основі просторів імен.

Ця робота була виконана в рамках KEP #5018, очолюваної WG Device Management та SIG Auth.

Пріоритетні альтернативи в ResourceClaims та ResourceClaimTemplates

Хоча робоче навантаження може найкраще працювати на одному високопродуктивному GPU, воно також може працювати на двох слабших GPU. З перемикачем функцій DRAPrioritizedList (тепер стандартно увімкнено) ResourceClaims та ResourceClaimTemplates отримують нове поле firstAvailable. Це поле є впорядкованим списком, що дозволяє користувачам вказувати, що запит може бути задоволений різними способами, включаючи виділення нічого, якщо специфічне обладнання недоступне. Планувальник намагатиметься задовольнити альтернативи в списку за порядком, тому робоче навантаження отримає найкращий набір доступних пристроїв у кластері.

Ця робота була виконана в рамках KEP #4816, очолюваної WG Device Management.

`kubelet` сповіщає про виділені ресурси DRA

API kubelet було оновлено для звіту про ресурси Pod, виділені через DRA. Це дозволяє агентам моніторингу вузлів виявляти виділені ресурси DRA для Podʼів на вузлі. Крім того, це дозволяє вузловим компонентам використовувати PodResourcesAPI та використовувати цю інформацію про DRA при розробці нових функцій та інтеграцій. Починаючи з Kubernetes v1.34, ця функція є стандартно увімкненою.

Ця робота була виконана в рамках KEP #3695, очолюваної WG Device Management.

Неблокуючі виклики API `kube-scheduler`

kube-scheduler виконує блокуючі API виклики під час циклів планування, створюючи вузькі місця в продуктивності. Ця функція впроваджує асинхронну обробку API через систему пріоритетних черг з дедуплікацією запитів, що дозволяє планувальнику продовжувати обробку Podʼів, поки операції API завершуються у фоновому режимі. Основні переваги включають зменшення затримки планування, запобігання голодування потоків планувальника під час затримок API та негайну можливість повторної спроби для незапланованих Podʼів. Реалізація зберігає зворотну сумісність і додає метрики для моніторингу очікуючих операцій API.

Ця робота була виконана в рамках KEP #5229, очолюваної SIG Scheduling.

Змінювані політики допуску

MutatingAdmissionPolicies пропонують декларативну, внутрішню альтернативу змінюваним веб-хукам допуску. Ця функція використовує інсталяцію обʼєктів CEL та стратегії JSON Patch, в поєднанні з алгоритмами злиття Server Side Apply. Це суттєво спрощує контроль допуску, дозволяючи адміністраторам визначати правила мутації безпосередньо в API сервері. Представлені як альфа у v1.32, політики мутації допуску стали бета у v1.34.

Ця робота була виконана в рамках KEP #3962, очолюваної SIG API Machinery.

Кеш сервера API, доступний для знімків

Механізм кешування kube-apiserver (кеш спостереження) ефективно обслуговує запити на останній спостережуваний стан. Однак, list запити на попередні стани (наприклад, через пагінацію або вказуючи resourceVersion) часто обходять цей кеш і обслуговуються безпосередньо з etcd. Це пряме звернення до etcd значно збільшує витрати на продуктивність і може призвести до проблем зі стабільністю, особливо з великими ресурсами, через тиск на памʼять від передачі великих обсягів даних. Зі стандартно увімкненою функцією ListFromCacheSnapshot kube-apiserver намагатиметься обслуговувати відповідь з моментальних знімків, якщо такий є з resourceVersion, старішим за запитуваний. kube-apiserver починає без знімків, створює новий знімок на кожну подію спостереження і зберігає їх, поки не виявить, що etcd стиснуто, або якщо кеш заповнений подіями старшими за 75 секунд. Якщо вказаний resourceVersion недоступний, сервер повернеться до etcd.

Ця робота була виконана в рамках KEP #4988, очолюваної SIG API Machinery.

Інструменти для декларативної перевірки типів, властивих Kubernetes

Перед цим випуском правила валідації для вбудованих у Kubernetes API писалися повністю вручну, що ускладнює їх виявлення, розуміння, покращення або тестування для супроводжуючих. Не було єдиного способу знайти всі правила валідації, які можуть застосовуватися до API. Декларативна валідація приносить користь супроводжувачам Kubernetes, спрощуючи розробку, обслуговування та перевірку API, одночасно дозволяючи програмну інспекцію для кращого інструментування та документації. Для людей, які використовують бібліотеки Kubernetes для написання свого коду (наприклад: контролера), новий підхід спрощує додавання нових полів через IDL теґи, а не складні функції валідації. Ця зміна допомагає прискорити створення API, автоматизуючи шаблони валідації, та надає більш релевантні повідомлення про помилки, виконуючи валідацію на версійованих типах. Це вдосконалення (яке стало бета у v1.33 і продовжується як бета у v1.34) приносить правила валідації на основі CEL до рідних типів Kubernetes. Це дозволяє визначати більш детальну та декларативну валідацію безпосередньо в визначеннях типів, покращуючи узгодженість API та взаємодію з розробниками.

Ця робота була виконана в рамках KEP #5073, очолюваної SIG API Machinery.

Потокові інформери для запитів list

Функція потокових інформерів, яка була в бета-версії з v1.32, отримує подальші вдосконалення бета-версії в v1.34. Ця можливість дозволяє list запитам повертати дані як безперервний потік обʼєктів з кешу спостереження API сервера, а не збиратися з пагінованих результатів безпосередньо з etcd. Повторюючи ті ж механізми, що використовуються для операцій watch, API сервер може обслуговувати великі набори даних, зберігаючи при цьому стабільне використання памʼяті та уникаючи піків алокації, які можуть вплинути на стабільність.

У цьому релізі kube-apiserver та kube-controller-manager обидва типово використовують новий механізм WatchList. Для kube-apiserver це означає, що запити списку тепер обслуговуються більш ефективно, тоді як kube-controller-manager отримує більш ефективний з точки зору памʼяті та передбачуваний спосіб роботи з інформерами. Разом ці покращення зменшують тиск на памʼять під час великих операцій list та покращують надійність під час тривалого навантаження, роблячи потокову передачу списків більш передбачуваною та ефективною.

Ця робота була виконана в рамках KEP #3157, очолюваної SIG API Machinery та SIG Scalability.

Управління належним вимкненням для вузлів на Windows

kubelet на вузлах Windows тепер може виявляти події завершення системи та починати належне завершення роботи запущених Podʼів. Це відображає існуючу поведінку на Linux і допомагає забезпечити чистий вихід робочих навантажень під час запланованих вимкнень або перезавантажень. Коли система починає вимикатися, kubelet реагує, використовуючи стандартну логіку завершення. Він поважає налаштовані хуки життєвого циклу та періоди належного вимкнення, надаючи Podʼам час на зупинку перед вимкненням вузла. Ця функція покладається на попереджувальні сповіщення Windows для координації цього процесу. Це вдосконалення покращує надійність робочих навантажень під час обслуговування, перезавантажень або оновлень системи. Тепер вона знаходиться в бета-версії та є стандартно увімкненою.

Ця робота була виконана в рамках KEP #4802, очолюваної SIG Windows.

Покращення в зміні розмірів Podʼа на місці

Підвищена до бета-версії та стандартно увімкнена у v1.33, функція зміни розміру Podʼа на місці отримує подальші вдосконалення в v1.34. До них відноситься підтримка зменшення використання памʼяті та інтеграція з ресурсами на рівні Podʼа.

Ця функція залишається в бета-версії в v1.34. Для отримання детальних інструкцій щодо використання та прикладів зверніться до документації: Зміна ресурсів CPU та памʼяті, призначених контейнерам.

Ця робота була виконана в рамках KEP #1287, очолюваної SIG Node та SIG Autoscaling.

Нові функції в Alpha

Це деякі з покращень, які тепер є альфа після випуску v1.34.

Сертифікати Pod для автентифікації mTLS

Автентифікація робочих навантажень всередині кластера, особливо для звʼязку з API сервером, в основному покладалася на токени ServiceAccount. Хоча це ефективно, ці токени не завжди є ідеальними для встановлення сильної, перевіряємої ідентичності для взаємного TLS (mTLS) і можуть створювати проблеми при інтеграції з зовнішніми системами, які очікують автентифікації на основі сертифікатів. Kubernetes v1.34 вводить вбудований механізм для Podʼів для отримання сертифікатів X.509 через PodCertificateRequests. kubelet може запитувати та керувати сертифікатами для Podʼів, які потім можуть використовуватися для автентифікації на сервері API Kubernetes та інших службах за допомогою mTLS. Основна перевага полягає в більш надійному та гнучкому механізмі ідентифікації для Podʼів. Це надає рідний спосіб реалізації надійної автентифікації mTLS без покладання виключно на маркерні токени, узгоджуючи Kubernetes зі стандартними практиками безпеки та спрощуючи інтеграцію з інструментами спостереження та безпеки, які використовують сертифікати.

Ця робота була виконана в рамках KEP #4317, очолюваної SIG Auth.

Стандарт безпеки Pod "Restricted" тепер забороняє віддалені перевірки

Поле host в рамках перевірок та обробників життєвого циклу дозволяє користувачам вказувати іншу сутність, ніж podIP, для перевірки kubelet. Однак, це відкриває шлях для зловживань та атак, які обходять засоби безпеки, оскільки поле host може бути встановлено на будь-яке значення, включаючи чутливі до безпеки зовнішні хости або localhost на вузлі. У Kubernetes v1.34, Podʼи відповідають стандарту безпеки Restricted лише в тому випадку, якщо вони або залишають поле host не налаштованим, або якщо вони навіть не використовують цей тип перевірки. Ви можете використовувати автоматизацію безпеки Pod, або сторонніх рішень, щоб забезпечити відповідність Podʼів цьому стандарту. Оскільки це засоби безпеки, ознайомтеся з документацією, щоб зрозуміти обмеження та поведінку механізму примусового виконання, який ви обираєте.

Ця робота була виконана в рамках KEP #4940, очолюваної SIG Auth.

Використовуйте `.status.nominatedNodeName` для показу розміщення Podʼа

Коли kube-scheduler затримується з привʼязкою Podʼів до вузлів, кластерні автомасштабувальники можуть не розуміти, що Pod буде привʼязаний до певного вузла. Внаслідок цього вони можуть помилково вважати вузол недовикористаним і видалити його. Щоб вирішити цю проблему, kube-scheduler може використовувати .status.nominatedNodeName не лише для вказівки на триваюче примусове виконання, але й для показу намірів розміщення Pod. Увімкнувши функціональну можливість NominatedNodeNameForExpectation, планувальник використовує це поле, щоб вказати, куди Pod буде призначений. Це відкриває внутрішні резервування, щоб допомогти зовнішнім компонентам приймати обґрунтовані рішення.

Ця робота була виконана в рамках KEP #5278, очолюваної SIG Scheduling.

Функції DRA в альфа-версії

Стан ресурсів для DRA

Може бути важко дізнатися, коли Pod використовує пристрій, який вийшов з ладу або тимчасово не працює, що ускладнює усунення неполадок, повʼязаних з аварією Pod. Стан справності ресурсу для DRA покращує спостережуваність, відкриваючи стан справності пристроїв, виділених Podʼу, у статусі Podʼа. Це полегшує виявлення причин проблем Podʼа, повʼязаних з несправними пристроями, та відповідь на них. Щоб увімкнути цю функціональність, потрібно активувати функціональну можливість ResourceHealthStatus, а драйвер DRA повинен реалізувати сервіс gRPC DRAResourceHealth.

Ця робота була виконана в рамках KEP #4680, очолюваної WG Device Management.

Зіставлення розширених ресурсів

Зіставлення розширених ресурсів надає простіший альтернативний DRA виразний та гнучкий підхід, пропонуючи простий спосіб опису ємності та споживання ресурсів. Ця функція дозволяє адміністраторам кластерів оголошувати ресурси, керовані DRA, як розширені ресурси, що дозволяє розробникам хастосунків та операторам продовжувати використовувати знайомий синтаксис контейнера .spec.resources для їх використання. Це дозволяє наявним робочим навантаженням приймати DRA без модифікацій, спрощуючи перехід на DRA як для розробників застосунків, так і для адміністраторів кластерів.

Ця робота була виконана в рамках KEP #5004, очолюваної WG Device Management.

Споживча спроможність DRA

У Kubernetes v1.33 додано підтримку драйверів ресурсів для оголошення доступних частин пристрою, замість того, щоб виставляти весь пристрій як ресурс «все або нічого». Однак, цей підхід не міг впоратися зі сценаріями, де драйвери пристроїв керують тонкими, динамічними частинами ресурсу пристрою на основі попиту користувача або ділять ці ресурси незалежно від ResourceClaims, які обмежені їх специфікацією та простором іменем. Увімкнення функціональної можливості DRAConsumableCapacity (представленої як альфа у v1.34) дозволяє драйверам ресурсів ділити один й той же пристрій, або навіть частину пристрою, між кількома ResourceClaims або між кількома DeviceRequests. Ця функція також розширює планувальник, щоб підтримувати виділення частин ресурсів пристрою, як визначено в полі capacity. Ця функція DRA покращує спільне використання пристроїв між просторами імен та заявками, налаштовуючи його на потреби Pod. Вона дозволяє драйверам забезпечувати обмеження ємності, покращує планування та підтримує нові випадки використання, такі як обізнаний про пропускну здатність мережевий звʼязок та багатокористувацьке спільне використання.

Ця робота була виконана в рамках KEP #5075, очолюваної WG Device Management.

Умови привʼязки пристроїв

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

Ця робота була виконана в рамках KEP #5007, очолюваної WG Device Management.

Правила перезапуску контейнерів

В даний час всі контейнери в межах Podʼа будуть дотримуватися однієї й тієї ж політики перезапуску .spec.restartPolicy під час виходу або аварії. Однак, Podʼи, які виконують кілька контейнерів, можуть мати різні вимоги до перезапуску для кожного контейнера. Наприклад, для ініціалізаційних контейнерів, які використовуються для виконання ініціалізації, ви, можливо, не захочете повторювати спроби ініціалізації, якщо вони зазнають невдачі. Аналогічно, в середовищах дослідження ML з тривалими навчальними навантаженнями, контейнери, які зазнають невдачі з кодами виходу, що підлягають повторному спробуванню, повинні швидко перезапускатися на місці, а не викликати відтворення Pod і втрату прогресу. Kubernetes v1.34 вводить перемикач функцій ContainerRestartRules. Коли він увімкнений, політика перезапуску може бути вказана для кожного контейнера в межах Pod. Також можна визначити список restartPolicyRules, щоб переважити restartPolicy на основі останнього коду виходу. Це надає детальний контроль, необхідний для обробки складних сценаріїв та кращого використання обчислювальних ресурсів.

Ця робота була виконана в рамках KEP #5307, очолюваної SIG Node.

Завантаження змінних середовища з файлів, створених під час виконання

Розробники застосунків давно просять про більшу гнучкість у оголошенні змінних середовища. Традиційно, змінні середовища оголошуються на стороні сервера API через статичні значення, ConfigMaps або Secrets.

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

Ця функція особливо корисна для навчальних навантажень AI/ML, де кожен Pod у навчальному завданні вимагає ініціалізації з значеннями, визначеними під час виконання.

Ця робота була виконана в рамках KEP #5307, очолюваної SIG Node.

Зміна станів, застарівання та видалення в v1.34

Перехід до стабільного стану

Це список усіх функцій, які стали стабільними (також відомими як загально доступні). Для отримання повного списку оновлень, включаючи нові функції та переходи з альфа- до бета-версії, дивіться примітки до випуску.

Цей реліз включає в себе в цілому 23 вдосконалення, які стали стабільними:

Застарівання та вилучення

Оскільки Kubernetes розвивається та росте, функції можуть застарівати, видалятися або замінюватися кращими для покращення загального стану проєкту. Дивіться політику застарівання та видалення для отримання додаткової інформації про цей процес. Випуск Kubernetes v1.34 містить кілька застарівань.

Ручна конфігурація драйвера cgroup застаріла

Історично, налаштування правильного драйвера cgroup було болючою точкою для користувачів, які використовували кластери Kubernetes. Kubernetes v1.28 додав спосіб для kubelet запитувати реалізацію CRI та дізнаватися, який драйвер cgroup використовувати. Це автоматичне виявлення тепер наполегливо рекомендується і підтримка цього функціоналу стала стабільною у v1.34. Якщо ваш CRI рушій виконання контейнерів не підтримує можливість повідомляти про драйвер cgroup, який йому потрібен, вам слід оновити або змінити його. Налаштування cgroupDriver у файлі конфігурації kubelet тепер застаріло. Відповідна опція командного рядка --cgroup-driver була раніше застаріла, оскільки Kubernetes рекомендує використовувати замість цього файл конфігурації. Як і налаштування конфігурації, так і опція командного рядка будуть видалені в майбутньому релізі, але це видалення не відбудеться раніше, ніж у мінорному релізі випуску v1.36.

Ця робота була виконана в рамках KEP #4033, очолюваної SIG Node.

Kubernetes припинить підтримку containerd 1.x у v1.36

Хоча Kubernetes v1.34 все ще підтримує containerd 1.7 та інші LTS релізи containerd, внаслідок автоматичного виявлення драйвера cgroup, спільнота Kubernetes SIG Node формально погодилася на остаточний графік підтримки для containerd v1.X. Останнім релізом Kubernetes, який запропонує цю підтримку, буде v1.35 (узгоджений з EOL containerd 1.7). Це раннє попередження про те, що якщо ви використовуєте containerd 1.X, розгляньте можливість переходу на 2.0+ найближчим часом. Ви можете моніторити метрику kubelet_cri_losing_support, щоб визначити, чи використовують якісь вузли у вашому кластері версію containerd, яка незабаром стане застарілою.

Ця робота була виконана в рамках KEP #4033, очолюваної SIG Node.

Розподіл трафіку `PreferClose` є застарілим

Поле spec.trafficDistribution в рамках Kubernetes Service дозволяє користувачам висловлювати переваги щодо того, як трафік повинен маршрутизуватися до точок доступу сервісу.

KEP-3015 визнає застарілим PreferClose і вводить два додаткових значення: PreferSameZone та PreferSameNode. PreferSameZone є псевдонімом для наявного PreferClose, щоб прояснити його семантику. PreferSameNode дозволяє зʼєднанням доставлятися до локальної точки доступу, коли це можливо, з переходом на віддалену точку доступу, коли це неможливо.

Ця функція була представлена у v1.33 під перемикачем функцій PreferSameTrafficDistribution. Вона стала бета у v1.34 і є стандартно увімкненою.

Ця робота була виконана в рамках KEP #3015, очолюваної SIG Network.

Примітки до випуску

Перегляньте всі деталі випуску Kubernetes v1.34 у наших примітках до випуску.

Доступність

Kubernetes v1.34 доступний для завантаження на GitHub або на сторінці Завантаження Kubernetes.

Щоб почати роботу з Kubernetes, ознайомтеся з цими інтерактивними навчальними посібниками або запустіть локальні кластери Kubernetes за допомогою minikube. Ви також можете легко встановити v1.34 за допомогою kubeadm.

Команда випуску

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

Ми вшановуємо памʼять Рудольфо "Родо" Мартінеса Веги, відданого учасника, чия пристрасть до технологій та побудови спільноти залишила слід у спільноті Kubernetes. Родо був учасником команди випуску Kubernetes протягом кількох релізів, включаючи v1.22-v1.23 та v1.25-v1.30, демонструючи непохитну відданість успіху та стабільності проєкту. Поза участтю в команді випуску, Родо активно сприяв розвитку спільноти Cloud Native LATAM, допомагаючи подолати мовні та культурні барʼєри в цій сфері. Його робота над іспанською версією документації Kubernetes та глосарію CNCF є прикладом його відданості справі зробити знання доступними для розробників, які говорять іспанською мовою, по всьому світу. Спадщина Родо живе через безліч членів спільноти, яких він наставляв, релізи, які він допоміг випустити, та яскраву спільноту Kubernetes LATAM, яку він допоміг виростити.

Ми хотіли б подякувати всій Команді випуску за години наполегливої праці, витрачені на підготовку релізу Kubernetes v1.34 для нашої спільноти. Членство в команді випуску варіюється від новачків до досвідчених лідерів команд з досвідом, набутих протягом кількох циклів випуску. Особлива подяка нашому лідеру випуску, Вйому Ядаву, за те, що провів нас через успішний цикл випуску, за його практичний підхід до вирішення викликів та за енергію та турботу, які рухають нашу спільноту вперед.

Швидкість проєкту

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

Під час циклу випуску v1.34, який тривав 15 тижнів з 19 травня 2025 року по 27 серпня 2025 року, Kubernetes отримав внески від 106 різних компаній та 491 особи. У ширшій хмарній екосистемі ця цифра зростає до 370 компаній, враховуючи 2235 загальних учасників.

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

Джерело цих даних:

Майбутні події

Ознайомтесь з майбутніми подіями Kubernetes та Cloud Native, включаючи KubeCon + CloudNativeCon, KCD та інші помітні конференції по всьому світу. Залишайтеся в курсі та беріть участь у житті спільноти Kubernetes!

Серпень 2025

KCD — Дні спільноти Kubernetes: Колумбія: 28 серпня 2025 року | Богота, Колумбія

Вересень 2025

CloudCon Sydney: 9–10 вересня 2025 року | Сідней, Австралія
KCD — Дні спільноти Kubernetes: Сан-Франциско: 9 вересня 2025 року | Сан-Франциско, США
KCD — Дні спільноти Kubernetes: Вашингтон: 16 вересня 2025 року | Вашингтон, округ Колумбія, США
KCD — Дні спільноти Kubernetes: Софія: 18 вересня 2025 року | Софія, Болгарія
KCD — Дні спільноти Kubernetes: Ель-Сальвадор: 20 вересня 2025 року | Сан-Сальвадор, Ель-Сальвадор

Жовтень 2025

KCD — Дні спільноти Kubernetes: Варшава: 9 жовтня 2025 року | Варшава, Польща
KCD — Дні спільноти Kubernetes: Единбург: 21 жовтня 2025 року | Единбург, Сполучене Королівство
KCD — Дні спільноти Kubernetes: Шрі-Ланка: 26 жовтня 2025 року | Коломбо, Шрі-Ланка

Листопад 2025

KCD — Дні спільноти Kubernetes: Порту: 3 листопада 2025 року | Порту, Португалія
KubeCon + CloudNativeCon Північна Америка 2025: 10-13 листопада 2025 року | Атланта, США
KCD — Дні спільноти Kubernetes: Ханчжоу: 15 листопада 2025 року | Ханчжоу, Китай

Грудень 2025

KCD — Дні спільноти Kubernetes: Швейцарська Романдія: 4 грудня 2025 року | Женева, Швейцарія

Ви можете знайти останні деталі подій тут.

Вебінар про майбутній реліз

Приєднуйтесь до членів команди випуску Kubernetes v1.34 у середу, 24 вересня 2025 року о 16:00 (UTC), щоб дізнатися про основні моменти цього випуску. Для отримання додаткової інформації та реєстрації відвідайте сторінку події на сайті CNCF Online Programs.

Долучайтесь

Найпростіший спосіб долучитися до Kubernetes — це приєднатися до однієї з багатьох Груп за інтересами (SIG, Special Interest Groups), які відповідають вашим інтересам. Маєте щось, що хочете донести до спільноти Kubernetes? Поділіться своїм голосом на нашій щотижневій зустрічі спільноти, а також через наведені нижче канали. Дякуємо за ваш постійний зворотний звʼязок та підтримку.

Слідкуйте за нами в Bluesky @Kubernetesio для отримання останніх оновлень
Приєднуйтесь до обговорення спільноти на Discuss
Приєднуйтесь до спільноти в Slack
Публікуйте запитання (або відповідайте на запитання) на Stack Overflow
Діліться своєю історією про Kubernetes
Читайте більше про те, що відбувається з Kubernetes в блозі
Дізнайтеся більше про Команду випуску Kubernetes

Налаштування Linux Swap для Kubernetes: детальний огляд

Tue, 19 Aug 2025 10:30:00 -0800

Функція Kubernetes NodeSwap, яка, ймовірно, отримає статус stable у майбутньому релізі Kubernetes v1.34, дозволяє використання swap: це значна зміна порівняно з традиційною практикою вимкнення swap для передбачуваної продуктивності. Ця стаття зосереджена виключно на налаштуванні swap на вузлах Linux, де ця функція доступна. Дозволяючи вузлам Linux використовувати вторинне сховище для додаткової віртуальної памʼяті, коли фізична RAM вичерпана, підтримка swap на вузлах спрямована на покращення використання ресурсів та зменшення кількості припинень процесів через нестачу памʼяті (OOM kills).

Однак, увімкнення swap не є рішенням "під ключ". Продуктивність та стабільність ваших вузлів під тиском на памʼять критично залежать від набору параметрів ядра Linux. Неправильна конфігурація може призвести до погіршення продуктивності та втручання в логіку виселення Kubelet.

У цьому дописі ми розглянемо критичні параметри ядра Linux, які керують поведінкою swap. Ми дослідимо, як ці параметри впливають на продуктивність робочих навантажень Kubernetes, використання swap та критичні механізми виселення. Також представимо різні результати тестів, що демонструють вплив різних конфігурацій, та поділимось своїми висновками щодо досягнення оптимальних налаштувань для стабільних та високопродуктивних кластерів Kubernetes.

Вступ до Linux swap

На високому рівні, ядро Linux керує памʼяттю через сторінки, зазвичай розміром 4КіБ. Коли фізична памʼять стає обмеженою, алгоритм заміни сторінок ядра вирішує, які сторінки перемістити у swap-простір. Хоча точна логіка є складною оптимізацією, на цей процес прийняття рішень впливають певні ключові фактори:

Шаблони доступу до сторінок (як часто сторінки використовуються)
"Забрудненість" сторінок (чи були сторінки модифіковані)
Тиск на памʼять (наскільки терміново системі потрібна вільна памʼять)

Анонімна памʼять проти памʼяті, що підтримується файлами

Важливо розуміти, що не всі сторінки памʼяті однакові. Ядро розрізняє анонімну памʼять та памʼять з файловою підтримкою.

Анонімна памʼять: Це памʼять, яка не підтримується конкретним файлом на диску, така як купа та стек програми. З точки зору програми це приватна памʼять, і коли ядру потрібно звільнити ці сторінки, воно повинно записати їх на спеціально відведений пристрій swap.

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

Хоча система без swap все ще може звільняти памʼять з чистими файлами під тиском, скидаючи їх, у неї немає способу скинути анонімну памʼять. Увімкнення swap надає цю можливість, дозволяючи ядру переміщати менш часто використовувані сторінки памʼяті на диск, щоб зберегти памʼять і уникнути використання механізму OOM-очищення системи.

Ключові параметри ядра для налаштування swap

Щоб ефективно налаштувати поведінку swap, Linux надає кілька параметрів ядра, якими можна керувати за допомогою sysctl.

vm.swappiness: Це найвідоміший параметр. Це значення від 0 до 200 (100 у старіших ядрах), яке контролює перевагу ядра для обміну анонімними сторінками памʼяті проти відновлення сторінок памʼяті з файловою підтримкою (кеш сторінок).
- Високе значення (наприклад, 90+): Ядро буде агресивно переміщувати в своп менш використовувану анонімну памʼять, щоб звільнити місце для кешу файлів.
- Низьке значення (наприклад, < 10): Ядро буде намагатися в першу чергу скинути сторінки кешу файлів, а не робити своп анонімній памʼяті.
vm.min_free_kbytes: Цей параметр вказує ядру зберігати мінімальну кількість памʼяті вільною як буфер. Коли кількість вільної памʼяті падає нижче цього буфера безпеки, ядро починає більш агресивно відновлювати сторінки (робити їх своп, а врешті-решт виконувати OOM-очищення).
- Функція: Це діє як запобіжник, щоб забезпечити ядру достатньо памʼяті для критичних запитів на виділення, які не можуть бути відкладені.
- Вплив на swap: Встановлення більшого min_free_kbytes ефективно підвищує мінімальне значення для вільної памʼяті, змушуючи ядро раніше ініціювати своп під час тиску на памʼять.
vm.watermark_scale_factor: Ця настройка контролює проміжок між різними водяними знаками: min, low та high, які обчислюються на основі min_free_kbytes.
- Пояснення водяних знаків:
  - low: Коли вільна памʼять нижча за цю позначку, процес ядра kswapd прокидається, щоб відновити сторінки у фоновому режимі. Саме тоді починається цикл свопу.
  - min: Коли вільна памʼять досягає цього мінімального рівня, агресивне відновлення сторінок блокує виділення процесів. Нездатність відновити сторінки призведе до OOM-очищень.
  - high: Відновлення памʼяті зупиняється, як тільки вільна памʼять досягає цього рівня.
- Вплив: Більший watermark_scale_factor створює більший буфер між водяними знаками low та min. Це дає kswapd більше часу для поступового відновлення памʼяті, перш ніж система потрапить у критичний стан.

У типовому серверному робочому навантаженні у вас може бути довготривалий процес з деякою памʼяттю, яка стає "холодною". Вищий показник swappiness може звільнити RAM, обмінюючи холодну памʼять, для інших активних процесів, які можуть виграти від збереження свого кешу файлів.

Налаштування параметрів min_free_kbytes та watermark_scale_factor для раннього переміщення вікна обміну надасть більше місця для kswapd, щоб скинути памʼять на диск і запобігти OOM-очищенням під час раптових сплесків потреби в памʼяті.

Тести та результати свопу

Щоб зрозуміти реальний вплив цих параметрів, ми провели серію стрес-тестів.

Налаштування тесту

Середовище: GKE на Google Cloud
Версія Kubernetes: 1.33.2
Конфігурація вузла: n2-standard-2 (8GiB RAM, 50GB swap на диску pd-balanced, без шифрування), Ubuntu 22.04
Робоче навантаження: Спеціально розроблена програма на Go, призначена для виділення памʼяті з налаштовуваною швидкістю, створення тиску на кеш файлів та імітації різних шаблонів доступу до памʼяті (випадковий проти послідовного).
Моніторинг: Контейнер-сайдкар, що захоплює системні метрики щосекунди.
Захист: Критичним системним компонентам (kubelet, середовище запуску контейнерів, sshd) було заборонено використовувати swap, встановивши memory.swap.max=0 у їхніх відповідних cgroups.

Методологія тестування

Був запущений под зі стрес-тестом на вузлах з різними налаштуваннями swappiness (0, 60 та 90) з варіюванням параметрів min_free_kbytes та watermark_scale_factor, щоб спостерігати за результатами під час сильного виділення памʼяті та тиску введення/виведення.

Візуалізація роботи свопу

Графік нижче, з тесту на стрес з швидкістю 100MBps, показує роботу swap. Коли вільна памʼять (на графіку "Використання памʼяті") зменшується, використання swap (Використано swap (GiB)) та активність swap-виводу (Swap Out (MiB/s)) зростають. Критично, оскільки система більше покладається на swap, також зростає I/O активність та відповідний час очікування (IO Wait % на графіку "Використання CPU"), що вказує на навантаження на CPU.

Висновки

Мої початкові тести з типовими параметрами ядра (swappiness=60, min_free_kbytes=68MB, watermark_scale_factor=10) швидко призвели до OOM-очищень і навіть несподіваних перезавантажень вузлів під час високого навантаження на памʼять. З вибором відповідних параметрів ядра можна досягти хорошого балансу між стабільністю вузла та продуктивністю.

Вплив `swappiness`

Параметр swappiness безпосередньо впливає на вибір ядра між відновленням анонімної памʼяті (свопом) та скиданням кешу сторінок. Щоб це спостерігати, я провів тест, у якому один под створював та утримував тиск на кеш файлів, після чого другий под виділяв анонімну памʼять зі швидкістю 100MB/s, щоб спостерігати за налаштуваннями ядра у відновленні:

Мої висновки виявили чіткий компроміс:

swappiness=90: Ядро проактивно робило своп неактивної анонімної памʼяті, щоб зберегти кеш файлів. Це призвело до високого та стабільного використання swap та значної I/O активності ("Blocks Out"), що, в свою чергу, викликало сплески очікування I/O на CPU.
swappiness=0: Ядро надавало перевагу скиданню сторінок кешу файлів, затримуючи споживання swap. Однак важливо розуміти, що це не вимикає своп. Коли тиск на памʼять був високим, ядро все ще робило своп анонімної памʼяті на диск.

Вибір залежить від робочого навантаження. Для робочих навантажень, чутливих до затримок введення/виведення, бажано нижче значення swappiness. Для робочих навантажень, які покладаються на великий та часто використовуваний кеш файлів, може бути корисним вищий показник swappiness, за умови, що диск достатньо швидкий, щоб впоратися з навантаженням.

Налаштування водяних знаків для запобігання виселенню та OOM kills

Найбільшою проблемою, з якою я зіткнувся, було взаємодія між швидким виділенням памʼяті та механізмом виселення Kubelet. Коли мій тестовий под, який навмисно був налаштований на перевищення памʼяті, виділяв її високими темпами (наприклад, 300-500 MBps), система швидко залишалася без вільної памʼяті.

Стандартно буфер для відновлення був занадто малим. Перш ніж kswapd встигав звільнити достатньо памʼяті шляхом свопу, вузол потрапляв у критичний стан, що призводило до двох можливих наслідків:

Виселення Kubelet Якщо менеджер виселення kubelet виявляв, що memory.available нижче його порогу, він виселяв под.
OOM-очищення У деяких сценаріях з високою швидкістю OOM-очищення активувалось би раніше, ніж виселення встигало завершитися, іноді вбиваючи поди вищого пріоритету, які не були джерелом тиску.

Щоб помʼякшити це, я налаштував водяні знаки:

Збільшено min_free_kbytes до 512MiB: Це змушує ядро почати відновлення памʼяті набагато раніше, забезпечуючи більший буфер безпеки.
Збільшено watermark_scale_factor до 2000: Це розширило проміжок між водяними знаками low та high (з ≈337MB до ≈591MB у моєму тестовому вузлі в /proc/zoneinfo), ефективно збільшуючи вікно обміну.

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

Таблиця порівнює рівні водяних знаків з /proc/zoneinfo (недоступний NUMA-узел):

`min_free_kbytes=67584KiB` та `watermark_scale_factor=10`	`min_free_kbytes=524288KiB` та `watermark_scale_factor=2000`
Вузол 0, зона Нормальна вільні сторінки 583273 підвищення 0 мін 10504 низький 13130 високий 15756 охоплено 1310720 присутній 1310720 керується 1265603	Вузол 0, зона Нормальна вільні сторінки 470539 мін 82109 низький 337017 високий 591925 охоплено 1310720 присутній 1310720 керується 1274542

Графік нижче показує, що розмір буфера ядра та коефіцієнт масштабування відіграють вирішальну роль у визначенні того, як система реагує на навантаження на памʼять. З правильним поєднанням цих параметрів система може ефективно використовувати простір swap, щоб уникнути виселення та підтримувати стабільність.

Ризики та рекомендації

Увімкнення swap у Kubernetes є потужним інструментом, але воно повʼязане з ризиками, якими потрібно управляти за допомогою ретельного налаштування.

Ризик погіршення продуктивності Своп значно повільніший, ніж доступ до RAM. Якщо активний робочий набір програми буде переміщено до свопу, її продуктивність різко постраждає через високі часи очікування введення/виведення (thrashing). Своп бажано забезпечити сховищем на базі SSD для покращення продуктивності.
Ризик маскування витоків пам'яті Своп може приховати витоки памʼяті в програмах, які інакше призвели б до швидкого OOM-очищення. З свопом програма з протіканням памʼяті може повільно погіршувати продуктивність вузла з часом, ускладнюючи діагностику першопричини.
Ризик відключення виселень Kubelet активно моніторить вузол на предмет тиску на памʼять та завершує поди, щоб відновити ресурси. Неправильне налаштування може призвести до OOM-очищень до того, як kubelet матиме можливість виселити поди відповідним чином. Правильно налаштований min_free_kbytes є критично важливим для забезпечення ефективності механізму виселення kubelet.

Kubernetes context

Разом, водяні знаки ядра та поріг виселення kubelet створюють серію зон тиску памʼяті на вузлі. Параметри порогу виселення потрібно відрегулювати, щоб налаштувати керовані Kubernetes виселення, які відбуваються до OOM-очищення.

Як показано на діаграмі, ідеальна конфігурація полягає в тому, щоб створити достатньо велике "вікно обміну" (між водяними знаками high та min), щоб ядро могло обробляти тиск памʼяті шляхом свопу, перш ніж доступна памʼять впаде в зону виселення/прямого відновлення.

Kubernetes Blog

Що потрібно знати перед міграцією: пʼять несподіваних особливостей поведінки Ingress-NGINX

1. Збіги регулярних виразів базуються на префіксах і не чутливі до регістру

2. nginx.ingress.kubernetes.io/use-regex застосовується до всіх шляхів хоста у всіх (Ingress-NGINX) Ingresses

3. Переписування цільового обʼєкта передбачає використання регулярного виразу

4. Запити, в яких відсутній кінцевий слеш, перенаправляються на той самий шлях з кінцевим слешем

5. Ingress-NGINX нормалізує URL-адреси

Підсумок

Представляємо контролер готовності вузлів

Навіщо потрібен контролер готовності вузлів?

Основні поняття та функції

Гнучкі режими виконання

Звіт про стан

Операційна безпека з тестовим запуском

Приклад: ініціалізація CNI

Приєднуйтесь

Нове перетворення з cgroup v1 CPU Shares на v2 CPU Weight

Історія

Проблеми з попередньою формулою перетворення

1. Зниження пріоритету порівняно з робочими навантаженнями, що не належать до Kubernetes

2. Некерована деталізація

Нова формула перетворення

Опис

Як це розвʼязує проблеми

Впровадження та інтеграція

Вплив на наявні розгортання

Де можна дізнатися більше?

Як долучитися?

Ingress NGINX: Заява комітетів з управління та реагування на загрози безпеки Kubernetes

Експерименти з Gateway API за допомогою kind

Увага:

Огляд

Передумови

Створення кластера kind

Встановлення cloud-provider-kind

Експериментування з Gateway API

Розгортання Gateway

Розгортання демо-застосунку

Створення HTTPRoute

Тестування вашого маршруту

Усунення несправностей

Перевірка стану Gateway

Перевірка стану HTTPRoute

Перевірка журналів контролера

Очищення

Видалення ресурсів Kubernetes

Зупинка cloud-provider-kind

Видалення кластера kind

Наступні кроки

Фінальне попередження

Cluster API v1.12: Впровадження оновлень на місці та ланцюгових оновлень

Акцент на простоті та зручності використання

Оновлення на місці

Ланцюгові оновлення

Команда випуску

Що далі?

Headlamp у 2025 році: ключові моменти проєкту

Оновлення

Приєднання до Kubernetes SIG UI

Програма наставництва від Linux Foundation

Нові зміни

Перегляд декількох кластерів

Проєкти

Навігація та дії

Пошук та мапа

OIDC та автентифікація

Каталог застосунків та Helm

Продуктивність, доступність та UX

Втулки та розширюваність

AI-асистент Headlamp

Додавання нових втулків

Інші оновлення втулків

Розробка втулків

Оновлення безпеки

Висновок

Оголошення про створення робочої групи Checkpoint/Restore Working Group

Мотивація та випадки використання

Повʼязані події

Звʼяжіться з нами

Уніфікований доступ до сервера API за допомогою clientcmd

2. `nginx.ingress.kubernetes.io/use-regex` застосовується до всіх шляхів хоста у всіх (Ingress-NGINX) Ingresses

Представляємо дію `RestartAllContainers`