# Проксі змішаних версій
LLMS index: [llms.txt](/llms.txt)
---
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.36 [beta](стандартно увімкнено)
У Kubernetes 1.36 включено бета-функцію, яка дозволяє API Server проксіювати запити ресурсів до інших _рівноправних_ API-серверів. Це також дозволяє клієнтам отримати цілісне уявлення про ресурси, що обслуговуються в усьому кластері, за допомогою виявлення. Це корисно, коли існують кілька API-серверів, що працюють на різних версіях Kubernetes в одному кластері (наприклад, під час тривалого впровадження нового релізу Kubernetes).
Це дозволяє адміністраторам кластерів налаштовувати високодоступні кластери, які можна оновлювати безпечніше:
1. гарантуючи, що контролери, які покладаються на виявлення для показу повного списку ресурсів для важливих завдань, завжди отримують повний огляд усіх ресурсів. Ми називаємо це повним виявленням у масштабі кластера — _Peer-aggregated discovery_.
1. направляючи запити на ресурси (зроблені під час оновлення) на відповідний kube-apiserver. Цей проксі заважає користувачам бачити несподівані помилки 404 Not Found, які випливають з процесу оновлення. Цей механізм називається _Mixed Version Proxy_.
## Активація Peer-aggregated Discovery та Mixed Version Proxy {#enabling-peer-aggregated-discovery-and-mixed-version-proxy}
Переконайтеся, що функціональну можливість [`UnknownVersionInteroperabilityProxy`](/docs/reference/command-line-tools-reference/feature-gates/#UnknownVersionInteroperabilityProxy) увімкнено, коли ви запускаєте API Server:
```shell
kube-apiserver \
--feature-gates=UnknownVersionInteroperabilityProxy=true \
# обовʼязкові аргументи командного рядка для цієї функції
--peer-ca-file=<шлях до сертифіката CA kube-apiserver>
--proxy-client-cert-file=<шлях до сертифіката агрегатора проксі>,
--proxy-client-key-file=<шлях до ключа агрегатора проксі>,
--requestheader-client-ca-file=<шлях до сертифіката CA агрегатора>,
# requestheader-allowed-names може бути встановлено як порожнє значення, щоб дозволити будь-яке Загальне Імʼя
--requestheader-allowed-names=<дійсні Загальні Імена для перевірки сертифікату клієнта проксі>,
# необовʼязкові прапорці для цієї функції
--peer-advertise-ip=`IP цього kube-apiserver, яке повинно використовуватися рівноправними для проксі-запитів`
--peer-advertise-port=`порт цього kube-apiserver, який повинен використовуватися рівноправними для проксі-запитів`
# …і інші прапорці як зазвичай
```
### Транспорт та автентифікація проксі між API-серверами {#transport-and-authn}
* Вихідний kube-apiserver повторно використовує
[наявні прапорці автентифікації клієнта API-сервера](/docs/tasks/extend-kubernetes/configure-aggregation-layer/#kubernetes-apiserver-client-authentication) `--proxy-client-cert-file` та `--proxy-client-key-file` для представлення своєї ідентичності, яку перевіряє його рівноправний (цільовий kube-apiserver). Цей останній підтверджує підключення рівноправного на основі конфігурації, яку ви вказуєте за допомогою аргументу командного рядка `--requestheader-client-ca-file`.
* Для автентифікації сертифікатів серверів призначення вам слід налаштувати пакет сертифікатів центру сертифікації, вказавши аргумент командного рядка `--peer-ca-file` **вихідному** API-серверу.
### Налаштування для зʼєднання з рівноправним API-сервером {#configuring-for-peer-api-server-connectivity}
Для встановлення мережевого розташування kube-apiserver, яке партнери будуть використовувати для проксі-запитів, використовуйте аргументи командного рядка `--peer-advertise-ip` та `--peer-advertise-port` для kube-apiserver або вказуйте ці поля в конфігураційному файлі API-сервера. Якщо ці прапорці не вказані, партнери будуть використовувати значення з аргументів командного рядка `--advertise-address` або `--bind-address` для kube-apiserver. Якщо ці прапорці теж не встановлені, використовується типовий інтерфейс хосту.
## Peer-aggregated discovery
Коли ви вмикаєте цю функцію, запити на виявлення автоматично вмикаються для надання комплексного документа виявлення (з переліком усіх ресурсів, що обслуговуються будь-яким apiserver у кластері).
Якщо ви хочете запросити документ виявлення, що не агрегується одноранговими вузлами, ви можете вказати це, додавши до запиту на виявлення такий заголовок Accept:
```none
application/json;g=apidiscovery.k8s.io;v=v2;as=APIGroupDiscoveryList;profile=nopeer
```
## Обробка змішаних версій {#mixed-version-proxying}
При активації обробки змішаних версій [шар агрегації](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) завантажує спеціальний фільтр, який виконує такі дії:
* Коли запит ресурсу надходить до API-сервера, який не може обслуговувати цей API (чи то тому, що він є версією, що передує введенню API, чи тому, що API вимкнено на API-сервері), API-сервер намагається надіслати запит до рівноправного API-сервера, який може обслуговувати затребуваний API. Це відбувається шляхом ідентифікації груп API / версій / ресурсів, які місцевий сервер не визнає, і спроби проксіювати ці запити до рівноправного API-сервера, який може обробити запит.
* Якщо рівноправний API-сервер не відповідає, то _source_ API-сервер відповідає помилкою 503 ("Сервіс недоступний").
### Як це працює під капотом {#how-it-works-under-the-hood}
Коли API-сервер отримує запит ресурсу, він спочатку перевіряє, які API-сервери можуть обслуговувати затребуваний ресурс. Ця перевірка відбувається за допомогою документа non peer-aggregated discovery.
* Якщо ресурс знаходиться у документі non peer-aggregated discovery отриманому від API-сервера, що отримав запит (наприклад, `GET /api/v1/pods/some-pod`), запит обробляється локально.
* Якщо ресурс у запиті (наприклад, `GET /apis/resource.k8s.io/v1beta1/resourceclaims`) не знайдено в документі виявлення, що не агрегується одноранговими вузлами, отриманому з API-сервера, який намагається обробити запит (_API-сервер обробки_), ймовірно, через те, що API `resource.k8s.io/v1beta1` був введений в новій версії Kubernetes, а _API-сервер обробки_ працює на старій версії, яка його не підтримує, тоді _API-сервер обробки_ отримує сервери API однорангових вузлів, які обслуговують відповідну групу API / версію / ресурс (у цьому випадку `resource.k8s.io/v1beta1/resourceclaims`) шляхом перевірки документів виявлення, що не агрегуються одноранговими серверами, з усіх однорангових API-серверів. Потім _API-сервер обробки_ проксіює запит до одного з відповідних однорангових kube-apiservers, які знають про запитуваний ресурс.
* Якщо для цієї групи API / версії / ресурсу немає відомого однорангового сервера, API-сервер обробки передає запит до власного ланцюжка обробників, який повинен зрештою повернути відповідь 404 («Не знайдено»).
* Якщо API-сервер обробки визначив і вибрав API-сервер-партнера, але цей партнер не відповідає (через проблеми з підключенням до мережі або станом перегонів даних між отриманим запитом і контролером, що реєструє інформацію про партнера в панелі управління), API-сервер обробки відповідає помилкою 503 («Service Unavailable»).