У працяг да нядаўняга для Яндэкс.Аблокі мы публікуем яшчэ адзін 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