Merge pull request #51786 from Andygol/uk-2025-07-28-kubernetes-v1.34-sneak-peek

Translation of the blog post 'Kubernetes v1.34 Sneak Peek' into Ukrainian

Author: k8s-ci-robot

content/uk/blog/_posts/2025-07-28-kubernetes-v1.34-sneak-peek.md

@@ -0,0 +1,118 @@
+---
+layout: blog
+title: Попередній огляд Kubernetes v1.34
+date: 2025-07-28
+slug: kubernetes-v1-34-sneak-peek
+author: >
+  Agustina Barbetta,
+  Alejandro Josue Leon Bellido,
+  Graziano Casto,
+  Melony Qin,
+  Dipesh Rawat
+---
+
+Kubernetes v1.34 очікукється наприкінці серпня 2025 року. Хоча він не міститиме видалень чи застарівань, у ньому буде велика кількість покращень. Ось деякі з функцій, які нас найбільше зацікавили в цьому циклі!
+
+Зверніть увагу, що ця інформація відображає поточний стан розробки v1.34 і може змінитися до випуску нової версії.
+
+## Основні покращення Kubernetes v1.34 {#featured-enhancements-of-kubernetes-v1-34}
+
+Нижче наведено деякі з помітних покращень, які, ймовірно, будуть включені до випуску v1.34, але це не вичерпний перелік усіх запланованих змін, і вміст релізу може змінюватися.
+
+### Ядро DRA переходить у стабільний стан {#the-core-of-dra-targets-stable}
+
+[Динамічний розподіл ресурсів](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) (DRA) забезпечує гнучкий спосіб категоризації, подання заявок та використання пристроїв, таких як GPU або спеціалізоване обладнання, у вашому кластері Kubernetes.
+
+З моменту випуску v1.30 DRA базується на заявках на пристрої із _структурованими параметрами_, які є непрозорими для ядра Kubernetes. Відповідна пропозиція ([KEP-4381](https://kep.k8s.io/4381)) щодо покращення, була створена під впливом концепцій динамічного виділення сховищ. DRA зі структурованими параметрами використовує набір допоміжних API-типів: ResourceClaim, DeviceClass, ResourceClaimTemplate та ResourceSlice у групі `resource.k8s.io`, а також розширює `.spec` для Pod новим полем `resourceClaims`. Ядро DRA планує перейти у стабільний стан у Kubernetes v1.34.
+
+З DRA драйвери пристроїв та адміністратори кластерів визначають класи пристроїв, доступні для використання. Робочі навантаження можуть подавати заявки на пристрої із зазначенням класу пристроїв у запитах. Kubernetes виділяє відповідні пристрої для конкретних заявок і розміщує відповідні Podʼи на вузлах, які мають доступ до виділених пристроїв. Ця система забезпечує гнучку фільтрацію пристроїв за допомогою CEL, централізовану категоризацію пристроїв та спрощені запити Podʼів.
+
+Після переходу цієї функції у стабільний стан API `resource.k8s.io/v1` буде стандартно доступний.
+
+### Токени ServiceAccount для автентифікації для завантаження образів {#serviceaccount-tokens-image-pull-authentication}
+
+Інтеграція токенів [ServiceAccount](/docs/concepts/security/service-accounts/) для провайдерів облікових даних `kubelet` ймовірно досягне бета-стадії та буде стандартно увімкнена у Kubernetes v1.34. Це дозволяє `kubelet` використовувати ці токени для завантаження контейнерних образів з реєстрів, які потребують автентифікації.
+
+Підтримка вже існує як alpha і відстежується у [KEP-4412](https://kep.k8s.io/4412).
+
+Alpha-інтеграція дозволяє `kubelet` використовувати короткострокові, токени ServiceAccount (з OIDC-сумісною семантикою) з автоматичною ротацією для автентифікації у реєстрі контейнерних образів. Кожен токен прив’язаний до відповідного Podʼа; механізм замінює потребу у довгострокових секретах для завантаження образів.
+
+Впровадження цього підходу знижує ризики безпеки, підтримує ідентичність на рівні робочого навантаження та зменшує операційні витрати. Це наближає автентифікацію при завантаженні образів до сучасних практик.
+
+### Політика заміни Pod в Deployment {#pod-replacement-policy-for-deployment}
+
+Після змін в [Deployment](/docs/concepts/workloads/controllers/deployment/) завершення Podʼів може тривати певний час і споживати додаткові ресурси. У рамках [KEP-3973](https://kep.k8s.io/3973) буде додано поле `.spec.podReplacementPolicy` (як alpha) для Deployment.
+
+Якщо функція увімкнена у вашому кластері, ви зможете обрати одну з двох політик:
+
+`TerminationStarted`
+: Створює нові Podʼи, як тільки старі починають процес завершення роботи, що прискорює оновлення, але може збільшити споживання ресурсів.
+
+`TerminationComplete`
+: Чекає повного завершення роботи старих Podʼів перед створенням нових, що забезпечує контрольоване споживання ресурсів.
+
+Ця функція робить поведінку Deployment більш передбачуваною, дозволяючи обирати, коли створювати нові Podʼи, під час оновлення чи масштабування. Це корисно для кластерів із обмеженими ресурсами або для навантажень із тривалим часом завершенням.
+
+Очікується, що функція буде доступна як alpha і може бути увімкнена через функціональні можливості `DeploymentPodReplacementPolicy` та `DeploymentReplicaSetTerminatingReplicas` в API-сервері та kube-controller-manager.
+
+### Готовий до промислового використання трейсинг для `kubelet` та API Server {#production-ready-tracing-for-kubelet-and-api-server}
+
+Для вирішення проблеми налагодження на рівні вузла шляхом зіставлення розрізнених логів, [KEP-2831](https://kep.k8s.io/2831) забезпечує глибоке, контекстне розуміння роботи `kubelet`.
+
+Функція інструментує критичні операції `kubelet`, особливо gRPC-виклики до Container Runtime Interface (CRI), використовуючи стандарт OpenTelemetry. Це дозволяє операторам візуалізувати весь життєвий цикл подій (наприклад, запуск Podʼів) для визначення джерел затримок та помилок. Найпотужніша частина — передача trace ID у запитах до контейнерного рушія, що дозволяє їм зв’язувати свої власні відрізки.
+
+Це доповнюється паралельним покращенням, [KEP-647](https://kep.k8s.io/647), яке приносить такі ж можливості трейсингу до API-сервера Kubernetes. Разом ці покращення забезпечують більш цілісний, наскрізний огляд подій, спрощуючи пошук затримок та помилок від панелі управління до вузла. Обидві функції пройшли офіційний процес релізу Kubernetes. [KEP-2831](https://kep.k8s.io/2831) був представлений як alpha у v1.25, а [KEP-647](https://kep.k8s.io/647) — як alpha у v1.22. Обидва були підвищені до beta у v1.27. У v1.34 планується, що вони перейдуть у стабільний стан.
+
+### `PreferSameZone` та `PreferSameNode` для розподілу трафіку у Service {#prefersamezone-and-prefersamenode-traffic-distribution-for-service}
+
+Поле `spec.trafficDistribution` у [Service](/docs/concepts/services-networking/service/) дозволяє вказати переваги щодо маршрутизації трафіку до точок доступу Service.
+
+[KEP-3015](https://kep.k8s.io/3015) визнає застарілим `PreferClose` та додає два нових значення: `PreferSameZone` та `PreferSameNode`. `PreferSameZone` еквівалентний поточному `PreferClose`. `PreferSameNode` надає перевагу надсиланню трафіку до точок доступу на тому ж вузлі, що й клієнт.
+
+Функція була представлена у v1.33 функціональною можливістю `PreferSameTrafficDistribution`. У v1.34 вона планує перейти у beta зі стандартним її увімкненням.
+
+### Підтримка KYAML: діалекту YAML для Kubernetes {#support-for-kyaml-a-kubernetes-dialect-of-yaml}
+
+KYAML — це безпечніша та менш неоднозначна підмножина YAML, спеціально розроблена для Kubernetes. Незалежно від версії Kubernetes, ви зможете використовувати KYAML для написання маніфестів чи Helm-чартів. Ви можете писати KYAML і передавати його як вхідні дані у **будь-яку** версію `kubectl`, оскільки всі KYAML-файли також є валідними YAML. З kubectl v1.34 очікується можливість запитувати вивід у форматі KYAML (`kubectl get -o kyaml …`). За бажанням, ви можете й надалі отримувати вихід у форматі JSON або YAML.
+
+KYAML вирішує специфічні проблеми YAML та JSON. У YAML значущі пробіли вимагають уважності до відступів та вкладеності, а необов’язкове взяття рядків в лапки може призвести до неочікуваного приведення типів (наприклад, ["The Norway Bug"](https://hitchdev.com/strictyaml/why/implicit-typing-removed/)). JSON не підтримує коментарі та має суворі вимоги до ком та ключів в лапках.
+
+[KEP-5295](https://kep.k8s.io/5295) представляє KYAML, який вирішує основні проблеми:
+
+* Обовʼязкове використання подвійних лапок для рядкових (string) значень
+
+* Не вказувати ключі в лапках, якщо вони не є потенційно неоднозначними
+
+* Завжди використовує `{}` для відображень (асоціативних масивів)
+
+* Завжди використовує `[]` для списків
+
+Це схоже на JSON, але на відміну від JSON, KYAML підтримує коментарі, дозволяє коми у кінці та не вимагає лапок для ключів.
+
+Очікуємо, що KYAML буде представлений як новий формат виводу для `kubectl` v1.34. Як і для всіх цих функцій, жодна з них не гарантована; слідкуйте за оновленнями!
+
+KYAML є і залишатиметься **строгою підмножиною YAML**, що гарантує можливість парсингу KYAML-документів будь-яким YAML-парсером. Kubernetes не вимагає спеціального формату KYAML для вхідних даних, і змінювати це не планується.
+
+### Точне регулювання автоматичного масштабування з налаштовуваною толерантністю HPA {#fine-grained-autoscaling-control-with-hpa-configurable-tolerance}
+
+[KEP-4951](https://kep.k8s.io/4951) додає можливість налаштовувати толерантність автомасштабування для кожного HPA окремо, замість стандартного кластерного значення 10%, яке часто є занадто грубим для різних навантажень. Покращення додає необов’язкове поле `tolerance` до секцій `spec.behavior.scaleUp` та `spec.behavior.scaleDown` HPA, дозволяючи різні значення толерантності для масштабування вгору та вниз, що особливо корисно, оскільки чутливість до масштабування вгору зазвичай важливіша для обробки піків трафіку.
+
+Функція була випущена як alpha у Kubernetes v1.33 з функціональною можливістю `HPAConfigurableTolerance`, а у v1.34 планує перейти у beta. Це покращення допомагає вирішити проблеми масштабування для великих розгортань, де толерантність для масштабування вниз на 10% може означати те, що в роботі залишаться сотні зайвих Podʼів. Новий підхід дозволяє оптимізувати поведінку для кожного навантаження окремо.
+
+## Хочете дізнатися більше? {#want-to-learn-more}
+
+Нові функції та застарівання також оголошуються у нотатках до релізу Kubernetes. Офіційний анонс новинок у [Kubernetes v1.34](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.34.md) буде частиною CHANGELOG для цього випуску.
+
+Випуск Kubernetes v1.34 заплановано на **середу, 27 серпня 2025 року**. Слідкуйте за оновленнями!
+
+## Долучайтеся {#get-involved}
+
+Найпростіший спосіб долучитися до Kubernetes — приєднатися до однієї з багатьох [Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIG), які відповідають вашим інтересам. Маєте щось, чим хочете поділитися з Kubernetes-спільнотою? Висловіть свою думку на щотижневій [community meeting](https://github.com/kubernetes/community/tree/master/communication) та через канали нижче. Дякуємо за ваші відгуки та підтримку!
+
+* Слідкуйте за нами у Bluesky [@kubernetes.io](https://bsky.app/profile/kubernetes.io) для останніх новин
+* Долучайтеся до обговорень на [Discuss](https://discuss.kubernetes.io/)
+* Долучайтеся до спільноти у [Slack](http://slack.k8s.io/)
+* Ставте питання (або відповідайте на них) на [Server Fault](https://serverfault.com/questions/tagged/kubernetes) або [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
+* Поділіться своєю Kubernetes [історією](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
+* Читайте більше про події у Kubernetes на [блозі](https://kubernetes.io/blog/)
+* Дізнайтеся більше про [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team)