Налаштування API-сервера розширення
Налаштування API-сервера розширення для роботи із шаром агрегації дає змогу розширювати API-сервер Kubernetes додатковими API, які не є частиною основних API Kubernetes.
Перш ніж ви розпочнете
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Для перевірки версії введіть kubectl version.
Налаштування API-сервера розширення для роботи із шаром агрегації
Наведені нижче кроки описують налаштування API-сервера розширення на високому рівні. Ці кроки застосовні незалежно від того, чи використовуєте ви конфігурації YAML, чи API. Ми намагаємося окремо вказати всі відмінності між цими двома підходами. Конкретний приклад їх реалізації за допомогою конфігурацій YAML дивіться в sample-apiserver у репозиторії Kubernetes.
Також можна використати наявне стороннє рішення, як-от apiserver-builder, яке має згенерувати каркас і автоматизувати всі наведені нижче кроки за вас.
- Переконайтеся, що API APIService увімкнено (перевірте
--runtime-config). Стандартно він має бути увімкнений, якщо його свідомо не вимкнули у вашому кластері. - Можливо, вам потрібно створити правило RBAC, яке дозволяє додавати обʼєкти APIService, або попросити про це адміністратора кластера. (Оскільки розширення API впливають на весь кластер, не рекомендовано тестувати, розробляти чи налагоджувати розширення API в робочому кластері.)
- Створіть простір імен Kubernetes, у якому ви хочете запустити свій api-service розширення.
- Створіть або отримайте сертифікат CA, який використовуватиметься для підпису серверного сертифіката, що його API-сервер розширення використовує для HTTPS.
- Створіть серверний сертифікат і ключ, які API-сервер використовуватиме для HTTPS. Цей сертифікат має бути підписаний наведеним вище CA. Він також повинен мати CN з іменем Kube DNS. Це імʼя походить від сервісу Kubernetes і має вигляд
<service name>.<service name namespace>.svc - Створіть Secret Kubernetes із серверним сертифікатом і ключем у вашому просторі імен.
- Створіть Deployment Kubernetes для API-сервера розширення й переконайтеся, що завантажуєте Secret як том. Він має містити посилання на робочий образ вашого API-сервера розширення. Deployment також має бути у вашому просторі імен.
- Переконайтеся, що ваш API-сервер розширення завантажує ці сертифікати з цього тому і що вони використовуються під час рукостискання HTTPS.
- Створіть службовий обліковий запис Kubernetes у вашому просторі імен.
- Створіть кластерну роль Kubernetes для операцій, які ви хочете дозволити над вашими ресурсами.
- Створіть привʼязку кластерної ролі Kubernetes від службового облікового запису у вашому просторі імен до створеної кластерної ролі.
- Створіть привʼязку кластерної ролі Kubernetes від службового облікового запису у вашому просторі імен до кластерної ролі
system:auth-delegator, щоб делегувати рішення щодо автентифікації основному API-серверу Kubernetes. - Створіть привʼязку ролі Kubernetes від службового облікового запису у вашому просторі імен до ролі
extension-apiserver-authentication-reader. Це дає вашому API-серверу розширення доступ до ConfigMap extension-apiserver-authentication. - Створіть apiservice Kubernetes. Наведений вище сертифікат CA має бути закодований у base64, без нових рядків, і використаний як spec.caBundle в apiservice. Він не має належати до простору імен. Якщо ви використовуєте kube-aggregator API, передавайте лише набір CA у кодуванні PEM, оскільки кодування base64 виконується за вас.
- Використайте kubectl, щоб отримати ваш ресурс. Під час виконання kubectl має повернути "No resources found.". Це повідомлення вказує, що все спрацювало, але наразі у вас немає створених обʼєктів цього типу ресурсу.
Що далі