istio · Andygol · Sep 11, 2024 · Nov 6, 2024 · Nov 6, 2024 · May 10, 2025
@@ -0,0 +1,30 @@
+---
+title: "Проєкт Istio оголошує результати виборів до Технічного наглядового комітету на 2025 рік"
+description: Оголошення результатів наших щорічних виборів.
+publishdate: 2025-08-19
+attribution: "Craig Box, for the Istio Steering Committee"
+keywords: [istio,toc,governance,community,election]
+---
+
+Минулого року ми оголосили, що Istio переходіть від моделі з технічним наглядовим комітетом з безстроковим призначенням на посади, на орган члени якого обираються на регулярній основі, а його члени будуть виконувати свої обовʼязки протягом двох років.
+
+Щороку обираються три з шести місць. Щоб запустити цей процес, ми оголосили, що вибори 2025 року охоплюватимуть місця, які займають три члени з найдовшим стажем.
+
+Одне з цих трьох місць стало вакантним, що спричинило проведення довиборів. Довголітний адміністратор [Костін Манолаче](https://github.com/costinm) виграв ці вибори. Ми дякуємо Костіну за його постійний внесок і завершення терміну повноважень, після чого він вирішив не балотуватися знову.
+
+Пʼять кандидатів балотувалися на три вільні місця, і Керівний комітет завершив вибори.
+
+**[Лін Сун](https://github.com/linsun)** та **[Луїс Райан](https://github.com/louiscryan)** були переобрані на свої два місця. Обидва брали участь у проєкті Istio ще до його публічного запуску і продовжують активно керувати проєктом.
+
+Третє місце зайняв **[Рама Чавалі](https://github.com/ramaraochavali)**, який вже давно бере участь у розробці та підтримці Istio, працюючи в компанії Salesforce.
+
+За словами самого Рами:
+
+{{< quote >}}   Я працюю з технологіями сервісної мережі більше восьми років, беручи участь у різних проєктах, що створили платформу Managed Mesh для Salesforce. Istio та Envoy є основою платформи сервісної мережі Salesforce, забезпечуючи роботу критично важливих робочих навантажень. Більшість трафіку Salesforce проходить через Istio та Envoy.
+
+З квітня 2019 року я є активним і впливовим учасником проєкту Istio. Мій внесок охоплює як основні компоненти панелі управління Istio та Envoy, так і високопродуктивний проксі-сервер, який служить панеллю даних Istio. Завдяки глибокому технічному розумінню та відданості проєкту, у січні 2020 року я був призначений адміністратором панелі управління Istio. Спираючись на цей досвід у сфері мережевих сервісних мереж, у липні 2020 року я став керівником робочої групи з мережевих технологій.
+
+Протягом усього часу роботи я відігравав важливу роль у формуванні проєкту Istio шляхом розробки та впровадження численних важливих функцій та архітектурних рішень.
+{{< /quote >}}
+
+Від імені спільноти Istio я вітаю Раму з обранням до TOC і сподіваюся на його подальше лідерство та вплив.
@@ -64,9 +64,9 @@ spec:
 
 У Istio ambient ця проблема вирішується за допомогою комбінації правил iptables і перекладу мережних адрес джерела (SNAT) для переписування лише тих пакетів, які явно походять від локального вузла, на фіксовану локальну IP-адресу, щоб їх можна було явно ігнорувати правилами виконання політики Istio як незахищений трафік перевірки справності. Локальна IP-адреса була обрана типово, оскільки зазвичай їх ігнорують для контролю ingress-egress, і, за [стандартом IETF](https://datatracker.ietf.org/doc/html/rfc3927), вони не маршрутизуються за межами локальної підмережі.
 
-Ця поведінка прозоро вмикається, коли ви додаєте podʼи до ambient mesh, і стандартно ambient використовує локальну адресу `169.254.7.127` для ідентифікації та правильного дозволу пакетів проб справності kubelet.
+Ця поведінка прозоро вмикається, коли ви додаєте podʼи до ambient mesh, і стандартно ambient використовує локальні адреси `169.254.7.127` (IPv4) та `fd16:9254:7127:1337:ffff:ffff:ffff:ffff` (IPv6) для ідентифікації та правильного дозволу пакетів проб справності kubelet.
 
-Однак якщо у вашому робочому навантаженні, просторі імен або кластері вже налаштований вхідний або вихідний `NetworkPolicy`, залежно від того, який CNI ви використовуєте, пакети з цією локальною адресою можуть бути заблоковані явним `NetworkPolicy`, що призведе до того, що перевірки справності podʼів вашого застосунку почнуть не виконуватися після додавання podʼів до ambient mesh.
+Примітка: якщо у вашому робочому навантаженні, просторі імен або кластері використовуються Kubernetes `NetworkPolicy`, ви маєте дозволити використання як адрес IPv4 так і IPv6 в режимі ambient. Залежно від того, який CNI ви використовуєте, пакети з цими адресами можуть бути заблоковані, що призведе до того, що перевірки справності podʼів вашого застосунку почнуть не виконуватися після додавання podʼів до ambient mesh.
 
 Наприклад, застосування наступного `NetworkPolicy` в просторі імен заблокує весь трафік (Istio чи інший) до podʼа `my-app`, **включаючи** проби справності kubelet. Залежно від вашого CNI, проби kubelet і локальні адреси можуть бути проігноровані цією політикою або заблоковані нею:
 
@@ -83,7 +83,7 @@ spec:
   - Ingress
 {{< /text >}}
 
-Після того, як pod буде зареєстровано в ambient mesh, пакети перевірки справності почнуть призначатися локальною адресою через SNAT, що означає, що проби справності можуть почати блокуватися вашим CNI при реалізації `NetworkPolicy`. Щоб дозволити пробам справності ambient обходити `NetworkPolicy`, явно дозвольте трафік від вузла до вашого podʼа, додавши до білого списку локальну адресу, яку використовує ambient для цього трафіку:
+Після того, як pod буде зареєстровано в ambient mesh, пакети перевірки справності почнуть призначатися локальною адресою через SNAT, що означає, що проби справності можуть почати блокуватися вашим CNI при реалізації `NetworkPolicy`. Щоб дозволити пробам справності ambient обходити `NetworkPolicy`, явно дозвольте трафік від вузла до вашого podʼа, додавши до білого списку локальні адреси, які використовує ambient для цього трафіку:
 
 {{< text syntax=yaml snip_id=none >}}
 apiVersion: networking.k8s.io/v1
@@ -99,3 +99,5 @@ spec:
       - ipBlock:
           cidr: 169.254.7.127/32
 {{< /text >}}
+
+Примітка: Якщо ви використовуєте кластер з подвійним стеком або кластер, що підтримує тільки IPv6, обовʼязково оновіть свою `NetworkPolicy`, додавши IPv6 ipBlock (`fd16:9254:7127:1337:ffff:ffff:ffff:ffff/128`) на додачу до запису IPv4 або замість нього.
@@ -25,6 +25,8 @@ Istio зазвичай маршрутизує трафік на основі HTT
 
 Для версій до 1.25 ви можете увімкнути перехоплення DNS, встановивши `values.cni.ambient.dnsCapture=true` та `values.pilot.env.PILOT_ENABLE_IP_AUTOALLOCATE=true` під час інсталяції.
 
+Окремі podʼи можуть відмовитися від глобального режиму збору даних DNS, застосувавши анотацію `ambient.istio.io/dns-capture=false`.
+
 ### Режим sidecar {#sidecar-mode}
 
 Ця функція наразі не увімкнена стандартно. Щоб її ввімкнути, встановіть Istio з такими налаштуваннями:

@@ -203,30 +203,13 @@ EOF
                         name: workload-socket
                         mountPath: "/run/secrets/workload-spiffe-uds"
                         readOnly: true
-                    - path: spec.template.spec.initContainers
-                      value:
-                        - name: wait-for-spire-socket
-                          image: busybox:1.36
-                          volumeMounts:
-                            - name: workload-socket
-                              mountPath: /run/secrets/workload-spiffe-uds
-                              readOnly: true
-                          env:
-                            - name: CHECK_FILE
-                              value: /run/secrets/workload-spiffe-uds/socket
-                          command:
-                            - sh
-                            - "-c"
-                            - |-
-                              echo "$(date -Iseconds)" Waiting for: ${CHECK_FILE}
-                              while [[ ! -e ${CHECK_FILE} ]] ; do
-                                echo "$(date -Iseconds)" File does not exist: ${CHECK_FILE}
-                                sleep 15
-                              done
-                              ls -l ${CHECK_FILE}
     EOF
     {{< /text >}}
 
+    {{< warning >}}
+    Якщо ви використовуєте Kubernetes 1.33 **і** не вимкнули підтримку [нативних sidecars](/blog/2023/native-sidecars/) у панелі управління Istio, ви повинні використовувати `initContainers` у шаблоні інʼєкції для sidecars. Це необхідно, оскільки підтримка нативних sidecars змінює спосіб інʼєкції sidecars. **ПРИМІТКА:** Шаблон інʼєкції SPIRE для шлюзів повинен продовжувати використовувати звичайні `containers`, як і раніше.
+    {{< /warning >}}
+
 1. Застосуйте конфігурацію:
 
     {{< text syntax=bash snip_id=apply_istio_operator_configuration >}}

@@ -61,9 +61,9 @@ Istio не гарантує, що мінорні релізи, які виход
 
 | Мінорні релізи | Виправлені версії без відомих CVE |
 |----------------|-----------------------------------|
-| 1.27.x         | 1.27.0+                           |
-| 1.26.x         | 1.26.0+                           |
-| 1.25.x         | 1.25.3+                           |
+| 1.27.x         | 1.27.1+                           |
+| 1.26.x         | 1.26.4+                           |
+| 1.25.x         | 1.25.5+                           |
 
 ## Підтримувані версії Envoy {#supported-envoy-versions}
 

@@ -103,7 +103,7 @@ test: yes
 
     {{< tab name="Автоматичне створення WorkloadEntry" category-value="autoreg" >}}
 
-    {{< boilerplate experimental >}}
+    {{< boilerplate alpha >}}
 
     {{< text syntax=bash snip_id=install_istio >}}
     $ istioctl install -f vm-cluster.yaml --set values.pilot.env.PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION=true --set values.pilot.env.PILOT_ENABLE_WORKLOAD_ENTRY_HEALTHCHECKS=true
@@ -224,7 +224,7 @@ EOF
 
 Спочатку створіть шаблон `WorkloadGroup` для віртуальної машини:
 
-{{< boilerplate experimental >}}
+{{< boilerplate alpha >}}
 
 {{< text syntax=bash snip_id=create_wg >}}
 $ cat <<EOF > workloadgroup.yaml
@@ -310,7 +310,7 @@ $ istioctl x workload entry configure -f workloadgroup.yaml -o "${WORK_DIR}" --c
 
 {{< tab name="Автоматизоване створення WorkloadEntry" category-value="autoreg" >}}
 
-{{< boilerplate experimental >}}
+{{< boilerplate alpha >}}
 
 {{< text syntax=bash snip_id=configure_wg >}}
 $ istioctl x workload entry configure -f workloadgroup.yaml -o "${WORK_DIR}" --clusterID "${CLUSTER}" --autoregister

@@ -530,7 +530,7 @@ EOF
 
 {{< tab name="Gateway API" category-value="gateway-api" >}}
 
-Оскільки Kubernetes Gateway API наразі не підтримує термінацію mutual TLS в [Gateway](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.Gateway), ми використовуємо Istio-специфічну опцію, `gateway.istio.io/tls-terminate-mode: MUTUAL`,  щоб зробити це:
+Додайте посилання на ConfigMap або Secret із ключем `ca.crt` або `cacert`, який містить сертифікати CA.
 
 {{< text bash >}}
 $ cat <<EOF | kubectl apply -f -
@@ -550,8 +550,11 @@ spec:
       mode: Terminate
       certificateRefs:
       - name: httpbin-credential
-      options:
-        gateway.istio.io/tls-terminate-mode: MUTUAL
+      frontendValidation:
+        caCertificateRefs:
+        - group: ""
+          kind: Secret
+          name: httpbin-credential
     allowedRoutes:
       namespaces:
         from: Selector
@@ -609,8 +612,7 @@ Istio підтримує кілька різних форматів секрет
 * TLS Secret з ключами `tls.key` і `tls.crt`, як описано вище. Для взаємного TLS, окремий загальний Secret з назвою `<secret>-cacert`, з ключем `cacert`. Наприклад, `httpbin-credential` має `tls.key` і `tls.crt`, а `httpbin-credential-cacert` має `cacert`.
 * Загальний Secret з ключами `key` та `cert`. Для взаємного TLS можна використовувати ключ `cacert`.
 * Загальний Secret з ключами `key` та `cert`. Для взаємного TLS можна використовувати окремий загальний секрет з назвою `<secret>-cacert`, який містить ключ `cacert`. Наприклад, `httpbin-credential` має `key` та `cert`, а `httpbin-credential-cacert` має `cacert`.
-* Для взаємного TLS можна посилатися на окремий загальний Secret з ключем `cacert` або `ca.crt` за допомогою `caCertCredentialName`. Він має перевагу над сертифікатами CA в Secret, на який посилаються з `credentialName(s)`.
-* Значення ключа `cacert` може бути зв'язкою сертифікатів CA, яка складається з окремих об'єднаних сертифікатів CA.
+* Значення ключа `cacert` може бути звʼязкою сертифікатів CA, яка складається з окремих обʼєднаних сертифікатів CA.
 
 ### SNI маршрутизація {#sni-routing}
 

@@ -1,7 +1,7 @@
 ---
 title: Випуски 1.24.x
 description: Анонси випуску 1.24 та повʼязаних з ним патчів.
-weight: 6
+weight: 5
 list_by_publishdate: true
 layout: release-grid
 decoration: dot

@@ -1,7 +1,7 @@
 ---
 title: Випуски 1.25.x
 description: Анонси для релізу 1.25 та його патч-релізів.
-weight: 6
+weight: 4
 list_by_publishdate: true
 layout: release-grid
 decoration: dot

@@ -0,0 +1,30 @@
+---
+title: Анонс Istio 1.25.5
+linktitle: 1.25.5
+subtitle: Патч-реліз
+description: Патч-реліз Istio 1.25.5.
+publishdate: 2025-09-03
+release: 1.25.5
+aliases:
+    - /news/announcing-1.25.5
+---
+
+Цей реліз містить виправлення помилок для покращення надійності. Ця примітка до релізу описує, що змінилося між Istio 1.25.4 та Istio 1.25.5.
+
+Цей випуск реалізує оновлення безпеки, описані в нашому повідомленні від 3 вересня, [`ISTIO-SECURITY-2025-001`](/news/security/istio-security-2025-001).
+
+{{< relnote >}}
+
+## Зміни {#changes}
+
+- **Виправлено** проблему, через яку `istio-iptables` іноді ігнорував стан IPv4 на користь стану IPv6 під час прийняття рішення про необхідність застосування нових правил iptables.
+  ([Issue #56587](https://github.com/istio/istio/issues/56587))
+
+- **Виправлено** помилку, через яку наш код спостереження за теґами не вважав стандартну ревізію такою ж, як стандартний теґ. Це могло спричинити проблеми, через які шлюзи Kubernetes не програмувалися.
+  ([Issue #56767](https://github.com/istio/istio/issues/56767))
+
+- **Виправлено** проблему, що спричиняла помилки під час інсталяції чарту Gateway з Helm v3.18.5 через більш суворий валідатор схеми JSON. Схема чарту була оновлена для забезпечення сумісності.
+  ([Issue #57354](https://github.com/istio/istio/issues/57354))
+
+- **Виправлено** проблему, коли опція `PreserveHeaderCase` перевизначала інші опції протоколу HTTP/1.x, такі як HTTP/1.0.
+  ([Issue #57528](https://github.com/istio/istio/issues/57528))