🥇Воведување на Kubernetes CCM (Cloud Controller Manager) за Yandex.Cloud

Во продолжение на неодамнешните Ослободување на возачот CSI за Yandex.Cloud објавуваме уште еден проект со отворен код за овој облак - Управувач со контролор на облак. CCM е потребен не само за кластерот како целина, туку и за самиот двигател на CSI. Деталите за неговата намена и некои карактеристики за имплементација се во сечењето.

Вовед

Зошто е ова?

Мотивите што нè поттикнаа да развиеме CCM за Yandex.Cloud целосно се совпаѓаат со оние што се веќе опишани во најава CSI драјвери. Одржуваме многу Kubernetes кластери од различни даватели на облак, за кои користиме една алатка. Имплементира бројни погодности „заобиколувајќи“ управуваните решенија на овие провајдери. Да, имаме прилично специфичен случај и потреби, но развојот на настаните создадени поради нив може да биде корисен за другите корисници.

Што точно е CCM?

Типично, ја подготвуваме околината околу нас за кластерот од надвор - на пример, користејќи Terraform. Но, понекогаш има потреба да управуваме со облачното опкружување околу нас од кластерот. Оваа можност е обезбедена, и токму таа се спроведува ССМ.

Поточно, 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 интерфејси.

И ова е она што го добивме.

Реализация

Како дојдовте до ова

Започнавме со развој (или подобро, дури и употреба) со готов(!) ССМ за Yandex.Cloud пред една година.

Сепак, во оваа имплементација ни недостасуваше:

автентикација преку JWT IAM токен;
Поддршка на сервисен контролер.

Во договор со авторот (длисин) во 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;
сметка на услугата за интеракција со Yandex.Cloud API. Во манифестот Secret е потребно пренесете овластени клучеви од сметката на услугата. Во документацијата опишано, како да креирате сметка за услуга и да добиете клучеви.

Ќе ни биде драго да ги добиеме вашите повратни информации и нови прашањаако наидете на некакви проблеми!

Резултатите од

Го користевме имплементираниот CCM во пет Kubernetes кластери во текот на изминатите две недели и планираме да го зголемиме нивниот број на 20 во наредниот месец. Во моментов не препорачуваме користење на CCM за големи и критични инсталации на K8.

Како и во случајот со CSI, ќе ни биде мило доколку програмерите на Yandex го преземат развојот и поддршката на овој проект - подготвени сме да го пренесеме складиштето на нивно барање за да се справиме со задачите што се порелевантни за нас.

PS

Прочитајте и на нашиот блог:

Извор: www.habr.com

Ви го претставуваме Kubernetes CCM (Cloud Controller Manager) за Yandex.Cloud