Kubernetes v1.28 [alpha](стандартно вимкнено)У Kubernetes 1.35 включено альфа-функцію, яка дозволяє API Server проксійовати запити ресурсів до інших рівноправних API-серверів. Це також дозволяє клієнтам отримати цілісне уявлення про ресурси, що обслуговуються в усьому кластері, за допомогою виявлення. Це корисно, коли існують кілька API-серверів, що працюють на різних версіях Kubernetes в одному кластері (наприклад, під час тривалого впровадження нового релізу Kubernetes).
Це дозволяє адміністраторам кластерів налаштовувати високодоступні кластери, які можна модернізувати безпечніше:
Переконайтеся, що функціональну можливість UnknownVersionInteroperabilityProxy увімкнено, коли ви запускаєте API Server:
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, який повинен використовуватися рівноправними для проксі-запитів`
# …і інші прапорці як зазвичай
Вихідний kube-apiserver повторно використовує
наявні прапорці автентифікації клієнта API-сервера --proxy-client-cert-file та --proxy-client-key-file для представлення своєї ідентичності, яку перевіряє його рівноправний (цільовий kube-apiserver). Цей останній підтверджує підключення рівноправного на основі конфігурації, яку ви вказуєте за допомогою аргументу командного рядка --requestheader-client-ca-file.
Для автентифікації сертифікатів серверів призначення вам слід налаштувати пакет сертифіката організації, вказавши аргумент командного рядка --peer-ca-file вихідному API-серверу.
Для встановлення мережевого розташування kube-apiserver, яке партнери будуть використовувати для проксі-запитів, використовуйте аргументи командного рядка --peer-advertise-ip та --peer-advertise-port для kube-apiserver або вказуйте ці поля в конфігураційному файлі API-сервера. Якщо ці прапорці не вказані, партнери будуть використовувати значення з аргументів командного рядка --advertise-address або --bind-address для kube-apiserver. Якщо ці прапорці теж не встановлені, використовується типовий інтерфейс хосту.
Коли ви вмикаєте цю функцію, запити на виявлення автоматично вмикаються для надання комплексного документа виявлення (з переліком усіх ресурсів, що обслуговуються будь-яким apiserver у кластері).
Якщо ви хочете запросити документ виявлення, що не агрегується одноранговими вузлами, ви можете вказати це, додавши до запиту на виявлення такий заголовок Accept:
application/json;g=apidiscovery.k8s.io;v=v2;as=APIGroupDiscoveryList;profile=nopeer
/apis, а не для запитів Unaggregated (Legacy) Discovery.При активації Mixed version proxying шар агрегації завантажує спеціальний фільтр, який виконує такі дії:
Коли 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»).