У наставку до недавно за Иандек.Цлоуд објављујемо још један пројекат отвореног кода за овај облак - . ЦЦМ је потребан не само за кластер у целини, већ и за сам ЦСИ драјвер. Детаљи о његовој намени и неким карактеристикама имплементације су испод.
Увод
Зашто је ово?
Мотиви који су нас подстакли да развијемо ЦЦМ за Иандек.Цлоуд потпуно се поклапају са онима који су већ описани у ЦСИ драјвери. Одржавамо много Кубернетес кластера различитих добављача облака, за које користимо један алат. Он имплементира бројне погодности „заобилазећи“ управљана решења ових провајдера. Да, имамо прилично специфичан случај и потребе, али развоји створени због њих могу бити корисни другим корисницима.
Шта је заправо ЦЦМ?
Обично припремамо окружење око нас за кластер споља - на пример, коришћењем Терраформа. Али понекад постоји потреба да се управља окружењем у облаку око нас из кластера. Ова могућност је обезбеђена и она се спроводи .
Конкретно, Цлоуд Цонтроллер Манагер пружа пет главних типова интеракције:
- Инстанцес – имплементира однос 1:1 између објекта чвора у Кубернетес-у (
Node) и виртуелну машину у добављачу облака. За ово ми:- попуните поље
spec.providerIDу објектуNode. На пример, за ОпенСтацк ЦЦМ ово поље има следећи формат:openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0. Можете видети име добављача облака и јединствени УУИД сервера (виртуелне машине у ОпенСтацк-у) објекта; - допуњују
nodeInfoу објектуNodeинформације о виртуелној машини. На пример, наводимо тип инстанце у АВС-у; - Проверавамо присуство виртуелне машине у облаку. На пример, ако објекат
Nodeотишао у стањеNotReady, можете проверити да ли виртуелна машина уопште постоји у провајдеру облака тако што ћетеproviderID. Ако га нема, избришите објекатNode, који би иначе заувек остао у кластеру;
- попуните поље
- Зоне – поставља домен грешке за објекат
Node, тако да планер може да изабере чвор за Под према регионима и зонама у провајдеру облака; - Распоређивање оптерећења – приликом креирања објекта
Serviceса типомLoadBalancerствара неку врсту балансера који ће усмеравати саобраћај споља ка чворовима кластера. На пример, у Иандек.Цлоуд можете користитиNetworkLoadBalancerиTargetGroupза ове сврхе; - Рута – гради мрежу између чворова, јер Према Кубернетес захтевима, сваки под мора да има своју ИП адресу и да може да дође до било којег другог модула. У ове сврхе можете користити преклапајућу мрежу (ВКСЛАН, ГЕНЕВЕ) или поставити табелу рутирања директно у виртуелној мрежи добављача облака:
- Запремина – Омогућава динамичко наручивање ПВ користећи ПВЦ и СЦ. У почетку је ова функционалност била део ЦЦМ-а, али је због велике сложености пребачена у посебан пројекат, Цонтаинер Стораге Интерфаце (ЦСИ). Причали смо о ЦСИ више пута и, као што је већ поменуто, чак ЦСИ драјвер.
Раније је сав код који је у интеракцији са облаком био смештен у главном Гит спремишту Кубернетес пројекта на адреси k8s.io/kubernetes/pkg/cloudprovider/providers, али су одлучили да то напусте због непријатности рада са великом базом кода. Све старе имплементације су премештене на . Ради погодности даље подршке и развоја, све заједничке компоненте су такође премештене .
Као и код ЦСИ-ја, многи велики добављачи облака су већ дизајнирали своје ЦЦМ-ове да искористе облаке на Кубернетес-у. Ако добављач нема ЦЦМ, али су све потребне функције доступне преко АПИ-ја, онда можете сами да имплементирате ЦЦМ.
Да бисте написали сопствену имплементацију ЦЦМ-а, довољно је да имплементирате .
И .
Имплементација
Како сте дошли до овога
Почели смо развој (тачније, чак и коришћење) са за Иандек.Цлоуд пре годину дана.
Међутим, у овој имплементацији нам је недостајало:
- аутентификација преко ЈВТ ИАМ токена;
- Подршка за сервисни контролер.
У договору са аутором (длисин) у Телеграму смо рачвали иандек-цлоуд-цонтроллер-манагер и додали функције које недостају.
Главне карактеристике
Тренутно, ЦЦМ подржава следеће интерфејсе:
- Инстанцес;
- Зоне;
- Распоређивање оптерећења.
У будућности, када Иандек.Цлоуд почне да ради са напредним ВПЦ могућностима, додаћемо интерфејс rute.
ЛоадБаланацер као главни изазов
У почетку смо покушали, као и друге ЦЦМ имплементације, да направимо пар LoadBalancer и TargetGroup за свакога Service са типом LoadBalancer. Међутим, Иандек.Цлоуд је открио једно занимљиво ограничење: не можете да користите TargetGroups са укрштањем Targets (пар SubnetID - IpAddress).
Стога се унутар креираног ЦЦМ-а покреће контролер, који при промени објеката Node прикупља информације о свим интерфејсима на свакој виртуелној машини, групише их према њиховој припадности одређеним NetworkID, ствара по TargetGroup на NetworkID, а такође прати релевантност. Након тога, приликом креирања објекта Service са типом LoadBalanacer једноставно прилажемо унапред креиран TargetGroup до нових NetworkLoadBalanacer'сам.
Како почети користити?
ЦЦМ подржава Кубернетес верзију 1.15 и новију. У кластеру, да би функционисао, потребна му је застава --cloud-provider=external био постављен на true за кубе-аписервер, кубе-цонтроллер-манагер, кубе-сцхедулер и све кубелетс.
Сви неопходни кораци за саму инсталацију су описани у . Инсталација се своди на креирање објеката у Кубернетесу из манифеста.
Да бисте користили ЦЦМ, такође ће вам требати:
- у манифесту идентификатор директоријума (
folder-id) Иандек.Цлоуд; - сервисни налог за интеракцију са Иандек.Цлоуд АПИ-јем. У манифесту
Secretморати са налога услуге. У документацији , како да креирате сервисни налог и добијете кључеве.
Биће нам драго да примимо ваше повратне информације и ако наиђете на било какве проблеме!
Резултати
Користили смо имплементирани ЦЦМ у пет Кубернетес кластера у протекле две недеље и планирамо да проширимо њихов број на 20 у наредном месецу. Тренутно не препоручујемо коришћење ЦЦМ-а за велике и критичне К8с инсталације.
Као иу случају ЦСИ, биће нам драго ако програмери Иандека преузму развој и подршку овог пројекта - спремни смо да пренесемо спремиште на њихов захтев како бисмо се бавили задацима који су нам релевантнији.
ПС
Прочитајте и на нашем блогу:
- «";
- «";
- «'.
Извор: ввв.хабр.цом