sync upstream

Author: Andygol

content/uk/_index.html

@@ -6,8 +6,6 @@
   priority: 1.0
 ---
 
-{{< site-searchbar >}}
-
 {{< blocks/section class="k8s-overview" >}}
 {{% blocks/feature image="flower" id="feature-primary" %}}
 

content/uk/blog/_posts/2025-03-24-kubernetes-1.33-sneak-peek.md

@@ -61,6 +61,8 @@ card:
 
 * [Використання admission-контролерів](/docs/reference/access-authn-authz/admission-controllers/) описує втулки, які перехоплюють запити до API Kubernetes після автентифікації та авторизації.
 
+* [Рекомендації щодо використання вебхуків допуску](/docs/concepts/cluster-administration/admission-webhooks-good-practices/) містить найкращі практики та міркування щодо створення мутованих вебхуків допуску та перевірки вебхуків допуску.
+
 * [Використання Sysctls в кластері Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) описує, як використовувати інструмент командного рядка `sysctl` для налаштування параметрів ядра.
 
 * [Аудит](/docs/tasks/debug-cluster/audit/) описує, як взаємодіяти з аудитом подій в Kubernetes.

content/uk/docs/concepts/cluster-administration/_index.md

@@ -34,6 +34,10 @@ API [Secret](/docs/concepts/configuration/secret/) надає базовий з
 
 Ви можете розгортати компоненти керування безпекою з ширшої екосистеми для впровадження компонентів для запобігання або виявлення небезпеки навколо Pod, їх контейнерів та образів, що запускаються у них.
 
+### Керування допуском {#admission-control}
+
+[Контролери допуску](/docs/reference/access-authn-authz/admission-controllers/) є втулками, які перехоплюють запити Kubernetes API та можуть їх перевіряти чи модифікувати за наявності певних полів в запиті. Продумане проєктування цих контролерів допомагає уникнути ненавмисних збоїв, оскільки API Kubernetes змінюються з оновленнями версій. Щодо міркувань з проєктування див. [Рекомендації щодо використання вебхуків допуску](/docs/concepts/cluster-administration/admission-webhooks-good-practices/).
+
 ### Аудит {#auditing}
 
 [Audit logging Kubernetes](/docs/tasks/debug/debug-cluster/audit/) забезпечує безпековий, хронологічний набір записів, що документують послідовність дій в кластері. Кластер перевіряє дії, породжені користувачами, застосунками, які використовують API Kubernetes, та самою панеллю управління.

content/uk/docs/concepts/cluster-administration/admission-webhooks-good-practices.md

@@ -272,10 +272,8 @@ spec:
 
 Підтримка розширення PersistentVolumeClaims (PVCs) є типово увімкненою. Ви можете розширити наступні типи томів:
 
-* azureFile (застарілий)
-* {{< glossary_tooltip text="csi" term_id="csi" >}}
+* {{< glossary_tooltip text="csi" term_id="csi" >}} (включно з деякими типами перенесених томів CSI)
 * flexVolume (застарілий)
-* rbd (застарілий)
 * portworxVolume (застарілий)
 
 Ви можете розширити PVC лише в тому випадку, якщо поле `allowVolumeExpansion` його класу сховища має значення true.
@@ -381,6 +379,7 @@ FlexVolumes (застарілий починаючи з Kubernetes v1.23) доз
 
 * [`cephfs`](/docs/concepts/storage/volumes/#cephfs) (**недоступно** починаючи з версії v1.31)
 * `flocker` — Flocker storage. (**недоступно** починаючи з версії v1.25)
+* `glusterfs` - GlusterFS storage. (**недоступно** починаючи з версії v1.26)
 * `photonPersistentDisk` — Photon controller persistent disk. (**недоступно** починаючи з версії v1.15)
 * `quobyte` — Том Quobyte. (**недоступно** починаючи з версії v1.25)
 * [`rbd`](/docs/concepts/storage/volumes/#rbd) — Rados Block Device (RBD) volume  (**недоступно** починаючи з версії v1.31)
@@ -515,13 +514,9 @@ PV може мати клас, який вказується, встановле
 
 Наступні типи томів підтримують параметри монтування:
 
-* `azureFile`
-* `cephfs` (**застаріло** в v1.28)
-* `cinder` (**застаріло** в v1.18)
+* `csi` (включно з деякими типами перенесених томів CSI)
 * `iscsi`
 * `nfs`
-* `rbd` (**застаріло** в v1.28)
-* `vsphereVolume`
 
 Параметри монтування не перевіряються на валідність. Якщо параметр монтування недійсний, монтування не вдасться.
 
@@ -677,14 +672,10 @@ PersistentVolume типу `hostPath` використовує файл або к
 
 Наступні втулки томів підтримують блокові томи, включаючи динамічне надання, де це можливо:
 
-* CSI
+* CSI (включно з деякими типами перенесених томів CSI)
 * FC (Fibre Channel)
 * iSCSI
 * Локальний том
-* OpenStack Cinder
-* RBD (застаріло)
-* RBD (Ceph Block Device; застаріло)
-* VsphereVolume
 
 ### PersistentVolume, що використовує блоковий том {#persistent-volume-using-a-raw-block-volume}
 

content/uk/docs/concepts/security/_index.md

@@ -73,25 +73,13 @@ Kubernetes перестав підтримуватися -->
 
 ### azureFile (застаріло) {#azurefile}
 
-{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
+<!-- maintenance note: OK to remove all mention of azureFile once the v1.30 release of Kubernetes has gone out of support -->
 
-Тип тому `azureFile` монтує том файлу Microsoft Azure (SMB 2.1 і 3.0) в Pod.
+У Kubernetes {{< skew currentVersion >}} всі операції для типу in-tree `azureFile` перенаправляються на драйвер `file.csi.azure.com` {{< glossary_tooltip text="CSI" term_id="csi" >}}.
 
-Для отримання докладнішої інформації див. [Втулок томів `azureFile`](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md).
+Вбудований драйвер сховища AzureFile було визнано застарілим у випуску Kubernetes v1.21, а потім повністю вилучено у випуску v1.30.
 
-#### Міграція до CSI для azureFile {#azurefile-csi-migration}
-
-{{< feature-state for_k8s_version="v1.26" state="stable" >}}
-
-Функція `CSIMigration` для `azureFile`, якщо увімкнена, перенаправляє всі операції втулка з наявного вбудованого втулка до драйвера інтерфейсу зберігання (Container Storage Interface, CSI) `file.csi.azure.com` контейнера. Для використання цієї функції необхідно встановити [Драйвер CSI для Azure File](https://github.com/kubernetes-sigs/azurefile-csi-driver) у кластері, і [функціональна можливість](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigrationAzureFile` має бути увімкненою.
-
-Драйвер CSI для Azure File не підтримує використання одного й того ж тому з різними fsgroups. Якщо `CSIMigrationAzureFile` увімкнено, використання одного й того ж тому з різними fsgroups взагалі не підтримується.
-
-#### Завершення міграції до CSI для azureFile {#azurefile-csi-migration-complete}
-
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
-
-Щоб вимкнути завантаження втулка сховища `azureFile` контролером і менеджером kubelet, встановіть прапорець `InTreePluginAzureFileUnregister` в значення `true`.
+Проєкт Kubernetes рекомендує замість нього використовувати сторонній драйвер сховища [Azure File](https://github.com/kubernetes-sigs/azurefile-csi-driver).
 
 ### cephfs (видалено) {#cephfs}
 
@@ -654,45 +642,13 @@ Kubernetes {{< skew currentVersion >}} не включає тип тому `rbd`
 
 ### vsphereVolume (застаріло) {#vspherevolume}
 
-{{< note >}}
-Проєкт Kubernetes рекомендує використовувати [vSphere CSI](https://github.com/kubernetes-sigs/vsphere-csi-driver) зовнішній драйвер сховища замість цього.
-{{< /note >}}
-
-`vsphereVolume` використовується для монтування тому vSphere VMDK у ваш Pod. Зміст тому зберігається при його демонтажі. Підтримуються обидва типи сховища VMFS та VSAN.
-
-Для отримання додаткової інформації дивіться [приклади томів vSphere](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere).
-
-### Міграція на vSphere CSI {#vsphere-csi-migration}
-
-{{< feature-state for_k8s_version="v1.26" state="stable" >}}
+<!-- maintenance note: OK to remove all mention of vsphereVolume once the v1.30 release of Kubernetes has gone out of support -->
 
 У Kubernetes {{< skew currentVersion >}}, всі операції для типу `vsphereVolume`, що використовується в інтегрованому стеку, перенаправляються на драйвер `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}}.
 
-Для цього має бути встановлений [драйвер CSI для vSphere](https://github.com/kubernetes-sigs/vsphere-csi-driver) на кластері. Додаткові поради щодо міграції з інтегрованого стеку `vsphereVolume` можна знайти на сторінці документації VMware [Migrating In-Tree vSphere Volumes to vSphere Container Storage Plug-in](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html). Якщо драйвер vSphere CSI не встановлено, не буде можливості виконати операції з томами, створеними за допомогою типу `vsphereVolume` з інтегрованим стеком.
+The `vsphereVolume` in-tree storage driver was deprecated in the Kubernetes v1.19 release and then removed entirely in the v1.30 release.
 
-Для успішної міграції до драйвера vSphere CSI вам слід використовувати vSphere версії 7.0u2 або пізніше.
-
-Якщо ви використовуєте версію Kubernetes відмінну від v{{< skew currentVersion >}}, перевірте документацію для цієї версії Kubernetes.
-
-{{< note >}}
-Наступні параметри StorageClass вбудованого втулка `vsphereVolume` не підтримуються драйвером vSphere CSI:
-
-- `diskformat`
-- `hostfailurestotolerate`
-- `forceprovisioning`
-- `cachereservation`
-- `diskstripes`
-- `objectspacereservation`
-- `iopslimit`
-
-Наявні томи, створені з використанням цих параметрів, будуть перенесені на драйвер vSphere CSI, але нові томи, створені драйвером vSphere CSI, не будуть враховувати ці параметри.
-{{< /note >}}
-
-#### Завершення міграція до vSphere CSI {#vsphere-csi-migration-complete}
-
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-
-Щоб вимкнути завантаження втулка `vsphereVolume` контролер-менеджером та kubelet, потрібно встановити прапорець  `InTreePluginvSphereUnregister` в значення `true`. Драйвер `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} повинен бути встановлений на всіх вузлах робочого навантаження.
+Проєкт Kubernetes пропонує замість цього використовувати драйвер сховища сторонніх розробників [vSphere CSI](https://github.com/kubernetes-sigs/vsphere-csi-driver).
 
 ## Використання subPath {#using-subpath}
 
@@ -863,12 +819,6 @@ spec:
 
 Вбудовані втулки, які підтримують `CSIMigration` і мають відповідний реалізований драйвер CSI перераховуються в [Типи томів](#volume-types).
 
-Підтримуються також вбудовані втулки, які підтримують постійне сховище на вузлах Windows:
-
-- [`azureFile`](#azurefile)
-- [`gcePersistentDisk`](#gcepersistentdisk)
-- [`vsphereVolume`](#vspherevolume)
-
 ### flexVolume (застаріло) {#flexvolume}
 
 {{< feature-state for_k8s_version="v1.23" state="deprecated" >}}

content/uk/docs/concepts/security/security-checklist.md

@@ -311,7 +311,7 @@ jwt:
     # всі вирази повинні бути true для успішної перевірки.
   - expression: 'claims.hd == "example.com"'
     # Повідомлення налаштовує повідомлення про помилку, яке відображається в логах сервера API, коли перевірка не вдається.
-    message: твердження hd повинно бути встановлено у example.com
+    message: вимога hd має бути встановлена на example.com
   - expression: 'claims.exp - claims.nbf <= 86400'
     message: загальний час життя токена не повинен перевищувати 24 години
   claimMappings:
@@ -329,8 +329,10 @@ jwt:
       #
       # 1.  Якщо у виразі username.expression використовується 'claims.email', то 'claims.email_verified' має бути використано у
       # username.expression або extra[*].valueExpression або claimValidationRules[*].expression.
-      # Приклад виразу правила валідації заявки, який автоматично збігається з валідацією
-      # застосовується, коли username.claim має значення 'email' - 'claims.?email_verified.orValue(true)'.
+      # Приклад виразу правила валідації вимоги, який автоматично збігається з валідацією
+      # застосовується, коли username.claim має значення 'email' - 'claims.?email_verified.orValue(true) == true'.
+      # Явно порівнюючи значення з true, ми дозволяємо перевірці типів побачити, що результат буде булевим, і
+      # щоб переконатися, що небулевий email_verified буде перехоплено під час виконання.
       # 2.  Якщо імʼя користувача, що оцінюється на основі виразу username.expression, є порожнім рядком, запит на автентифікацію
       # запит не буде виконано.
       expression: 'claims.username + ":external-user"'