🥇Представяме ви Kubernetes CCM (Cloud Controller Manager) за Yandex.Cloud

В продължение на скорошното Издаване на CSI драйвер за Yandex.Cloud публикуваме друг проект с отворен код за този облак - Мениджър на облачен контролер. CCM е необходим не само за клъстера като цяло, но и за самия CSI драйвер. Подробности за предназначението му и някои характеристики на изпълнение са под разреза.

въведение

Защо е това?

Мотивите, които ни подтикнаха да разработим CCM за Yandex.Cloud, напълно съвпадат с вече описаните в съобщение CSI драйвери. Ние поддържаме много Kubernetes клъстери от различни облачни доставчици, за които използваме един инструмент. Той прилага множество удобства, „заобикаляйки“ управляваните решения на тези доставчици. Да, имаме доста специфичен случай и нужди, но разработките, създадени заради тях, могат да бъдат полезни за други потребители.

Какво точно е CCM?

Обикновено ние подготвяме средата около нас за клъстера отвън - например с помощта на Terraform. Но понякога има нужда да управляваме облачната среда около нас от клъстер. Тази възможност е предвидена и именно тя се реализира CCM.

По-конкретно, Cloud Controller Manager предоставя пет основни типа взаимодействие:

Случаите – прилага връзка 1:1 между обект на възел в Kubernetes (Node) и виртуална машина в облачния доставчик. За това ние:
- попълнете полето spec.providerID в обекта Node. Например за OpenStack CCM това поле има следния формат: openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Можете да видите името на облачния доставчик и уникалния UUID на сървъра (виртуална машина в OpenStack) на обекта;
- допълнение nodeInfo в обекта Node информация за виртуалната машина. Например, ние посочваме тип инстанция в AWS;
- Проверяваме наличието на виртуална машина в облака. Например, ако обект Node отиде в състояние NotReady, можете да проверите дали виртуалната машина изобщо съществува в облачния доставчик чрез providerID. Ако не е там, изтрийте обекта Node, които иначе биха останали в клъстера завинаги;
Зони – задава домейна на отказ за обекта 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, е достатъчно да внедрите необходими Go интерфейси.

И това е, което имаме.

Изпълнение

Как се стигна до това

Започнахме разработката (или по-скоро дори използването) с готов(!) CCM за Yandex.Cloud преди година.

В тази реализация обаче ни липсваше:

удостоверяване чрез JWT IAM токен;
Поддръжка на сервизен контролер.

В съгласие с автора (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 и всички kubelets.

Всички необходими стъпки за самата инсталация са описани в README. Инсталирането се свежда до създаване на обекти в Kubernetes от манифести.

За да използвате CCM, ще ви трябва също:

посочете в манифеста идентификаторът на директорията (folder-id) Yandex.Cloud;
акаунт за услуга за взаимодействие с API на Yandex.Cloud. В манифеста Secret необходимо прехвърляне на оторизирани ключове от сервизния акаунт. В документацията описано, как да създадете сервизен акаунт и да получите ключове.

Ще се радваме да получим вашите отзиви и нови проблемиако срещнете проблеми!

Резултати от

Използвахме внедрения CCM в пет клъстера на Kubernetes през последните две седмици и планираме да разширим броя им до 20 през следващия месец. В момента не препоръчваме използването на CCM за големи и критични инсталации на K8s.

Както в случая с CSI, ще се радваме, ако разработчиците на Yandex поемат разработването и поддръжката на този проект - ние сме готови да прехвърлим хранилището по тяхно искане, за да се справим със задачи, които са по-подходящи за нас.

PS

Прочетете също в нашия блог:

Източник: www.habr.com

Представяме ви Kubernetes CCM (Cloud Controller Manager) за Yandex.Cloud