Протягом недавнього для Яндекс.Хмари ми публікуємо ще один Open Source-проект для цієї хмари . CCM необхідний як кластера загалом, а й власне CSI-драйвера. Подробиці про його призначення та деякі особливості реалізації – під катом.
Запровадження
Навіщо це?
Мотиви, які спонукали нас до розробки CCM для Яндекс.Хмари, повністю збігаються з описаними в CSI-драйвера. Ми обслуговуємо багато Kubernetes-кластерів у різних хмарних провайдерів, для чого використовуємо єдиний інструмент. Він реалізує численні зручності «в обхід» managed-рішень цих провайдерів. Так, у нас досить специфічний випадок та потреби, проте створені через них напрацювання можуть стати в нагоді й іншим користувачам.
Що таке CCM?
Як правило, ми готуємо навколишнє середовище для кластера зовні - Наприклад, за допомогою Terraform. Але іноді є необхідність керувати навколишнім хмарним середовищем із кластера. Така можливість передбачена, і саме її реалізує .
Зокрема, Cloud Controller Manager забезпечує п'ять основних типів взаємодії:
- Примірники – реалізує зв'язок 1:1 між об'єктом вузла Kubernetes (
Node) та віртуальною машиною в хмарному провайдері. Для цього ми:- заповнюємо поле
spec.providerIDв об'єктіNode. Наприклад, для OpenStack CCM це поле має такий формат:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Можна бачити ім'я хмарного провайдера та унікальний UUID server'а (віртуальна машина в OpenStack) об'єкта; - доповнюємо
nodeInfoв об'єктіNodeінформацією про віртуальну машину. Наприклад, вказуємо instance type в AWS; - перевіряємо наявність віртуальної машини у хмарі. Наприклад, якщо об'єкт
Nodeперейшов у станNotReady, можна перевірити, чи існує взагалі віртуальна машина в хмарному провайдеріproviderID. Якщо її немає – видаляємо об'єктNode, який інакше залишився в кластері надовго;
- заповнюємо поле
- Зони - Задає failure domain для об'єкта
Nodeщоб планувальник міг вибрати вузол для Pod'а відповідно до регіонів та зон у хмарному провайдері; - LoadBalancer – під час створення об'єкта
Serviceз типомLoadBalancerстворює якийсь балансувальник, який спрямує трафік ззовні до вузлів кластера. Наприклад, у Yandex.Cloud можна використовуватиNetworkLoadBalancerиTargetGroupдля цих цілей; - Маршрут - Будує мережу між вузлами, т.к. за вимогами Kubernetes кожен pod повинен мати свою IP-адресу та мати можливість достукатися до будь-якого іншого pod'а. Для цього можна використовувати оверлейну мережу (VXLAN, GENEVE) або задати таблицю маршрутизації прямо у віртуальній мережі хмарного провайдера:
- Об'єм – дозволяє динамічно замовляти PV, використовуючи PVC та SC. Спочатку цей функціонал був частиною CCM, але через велику складність був винесений в окремий проект Container Storage Interface (CSI). Про CSI ми не раз і, як уже говорилося, навіть CSI-драйвер.
Раніше весь код, що взаємодіє зі хмарою, лежав в основному Git-репозиторії проекту Kubernetes за адресою k8s.io/kubernetes/pkg/cloudprovider/providersАле від цього вирішили відмовитися через незручність роботи з великою кодовою базою. Усі старі реалізації були винесені до . Для зручності подальшої підтримки та розробки всі загальні компоненти теж були винесені у .
Як і у випадку з CSI, багато великих постачальників хмарних послуг вже розробили свої CCM для використання хмар у Kubernetes. Якщо CCM у постачальника немає, але всі необхідні функції доступні через API, то можна реалізувати CCM самостійно.
Щоб написати свою реалізацію CCM, достатньо реалізувати .
И .
Реалізація
Як прийшли до цього
Розробку (а точніше навіть використання) ми почали з для Yandex.Cloud річної давності.
Однак у цій реалізації нам не вистачало:
- аутентифікації через JWT IAM-токен;
- підтримки Service controller'а.
За погодженням з автором (Dlisin) у Telegram, ми форкнули yandex-cloud-controller-manager та дописали відсутні функції.
Основні можливості
На даний момент CCM підтримує такі інтерфейси:
- Примірники;
- Зони;
- LoadBalancer.
У майбутньому, коли Yandex.Cloud почне працювати з просунутими можливостями VPC, ми додамо інтерфейс Маршрути.
LoadBalanacer як головний виклик
Спочатку ми пробували, як у інших реалізацій CCM, створювати пару LoadBalancer и TargetGroup для кожного Service з типом LoadBalancer. Однак у Yandex.Cloud виявилося одне цікаве обмеження: не можна використовувати TargetGroups з перетинаються Targets (пара SubnetID - IpAddress).
Тому всередині створеного CCM запускається контролер, який при зміні об'єктів Node збирає інформацію про всі інтерфейси на кожній віртуальній машині, групує їх за належністю до певних NetworkID, створює за TargetGroup на NetworkID, а також слідкує за актуальністю. Згодом, під час створення об'єкта Service з типом LoadBalanacer ми просто прикріплюємо заздалегідь створену TargetGroup до нових NetworkLoadBalanacerТам.
Як почати користуватися?
CCM підтримує Kubernetes версії 1.15 та вище. У кластері для його роботи потрібно, щоб прапор --cloud-provider=external був встановлений у значення true для kube-apiserver, kube-controller-manager, kube-scheduler та всіх kubelet'ів.
Всі необхідні кроки по самій установці описані в . Інсталяція зводиться до створення об'єктів у Kubernetes з маніфестів.
Для використання CCM також знадобиться:
- у маніфесті ідентифікатор каталогу (
folder-id) Яндекс.Хмари; - сервісний обліковий запис для взаємодії з API Яндекс.Хмари. У маніфесті
Secretнеобхідно від сервісного облікового запису. У документації Як створити сервісний обліковий запис і отримати ключі.
Будемо раді зворотного зв'язку та , якщо зіткнетеся з якимись проблемами!
Підсумки
Реалізовану CCM ми використовуємо у п'яти Kubernetes-кластерах протягом двох останніх тижнів і плануємо розширити їх число до 20 найближчого місяця. Використовувати CCM для великих та критичних інсталяцій K8s зараз не рекомендуємо.
Як і у випадку з CSI, будемо раді, якщо розробники Яндекса візьмуть на себе розвиток та підтримку цього проекту — ми готові передати репозиторій на їхнє прохання, щоб займатися більш профільними для нас завданнями.
PS
Читайте також у нашому блозі:
- «»;
- «»;
- «».
Джерело: habr.com