Наладзіць захоўванне дадзеных прыкладанняў, запушчаных у кластары Kubernetes, можна некалькімі спосабамі. Адны з іх ужо састарэлі, іншыя з'явіліся зусім нядаўна. У гэтым артыкуле разгледзім канцэпцыю трох варыянтаў падлучэння СХД, у тым ліку самы апошні – падлучэнне праз Container Storage Interface.
Спосаб 1. Указанне PV у маніфесце
Тыповы маніфест, які апісвае пад у кластары Kubernetes:
Колерам вылучаныя часткі маніфесту, дзе апісана, які том падключаецца і куды.
У раздзеле volumeMounts паказваюць кропкі мантавання (mountPath) - у які каталог усярэдзіне кантэйнера будзе манціравацца пастаянны том, а таксама імя тома.
У раздзеле x пералічваюць усе тамы, якія выкарыстоўваюцца ў подзе. Паказваюць імя кожнага тома, а таксама тып (у нашым выпадку: awsElasticBlockStore) і параметры падключэння. Якія менавіта параметры пералічваюцца ў маніфесце, залежыць ад тыпу тома.
Адзін і той жа том можа быць змантаваны адначасова ў некалькі кантэйнераў пода. Такім чынам розныя працэсы прыкладання могуць мець доступ да адных і тым жа дадзеным.
Гэты спосаб падлучэння прыдумалі ў самым пачатку, калі Kubernetes толькі зараджаўся, і на сёння спосаб састарэлы.
Пры яго выкарыстанні ўзнікае некалькі праблем:
- усе тамы трэба ствараць уручную, Kubernetes не зможа стварыць нічога за нас;
- параметры доступу да кожнага з тамоў унікальныя, і іх трэба ўказваць у маніфестах усіх подаў, якія выкарыстоўваюць том;
- каб памяняць сістэму захоўвання (напрыклад, пераехаць з AWS у Google Cloud), трэба мяняць налады і тып падлучаных тамоў ва ўсіх маніфестах.
Усё гэта вельмі няёмка, таму ў рэальнасці падобным спосабам карыстаюцца для падлучэння толькі некаторых адмысловых тыпаў тамоў: configMap, secret, emptyDir, hostPath:
-
configMap і secret - службовыя тамы, дазваляюць стварыць у кантэйнеры том з файламі з маніфестаў Kubernetes.
-
emptyDir - часовы том, ствараецца толькі на час жыцця пода. Зручна выкарыстоўваць для тэсціравання або захоўвання часовых дадзеных. Калі pod выдаляецца, тым тыпу emptyDir таксама выдаляецца і ўсе дадзеныя знікаюць.
-
hostPath - дазваляе змантаваць унутр кантэйнера з дадаткам любы каталог лакальнага дыска сервера, на якім працуе дадатак, - у тым ліку /etc/kubernetes. Гэта небяспечная магчымасць, таму звычайна палітыкі бяспекі забараняюць выкарыстоўваць тамы гэтага тыпу. Інакш прыкладанне зламысніка зможа замантаваць унутр свайго кантэйнера каталог HTC Kubernetes і выкрасці ўсе сертыфікаты кластара. Як правіла, тамы hostPath дазваляюць выкарыстоўваць толькі сістэмным прыкладанням, якія запускаюцца ў namespace kube-system.
прыведзены ў дакументацыі.
Спосаб 2. Падлучэнне да падоў SC/PVC/PV
Альтэрнатыўны спосаб падлучэння – канцэпцыя Storage class, PersistentVolumeClaim, PersistentVolume.
Клас захоўвання захоўвае параметры падлучэння да сістэмы захоўвання дадзеных.
PersistentVolumeClaim апісвае патрабаванні да таго, які патрэбен з дадаткам.
PersistentVolume захоўвае параметры доступу і статус тома.
Іста ідэі: у маніфесце пода паказваюць volume тыпу PersistentVolumeClaim і паказваюць назву гэтай сутнасці ў параметры claimName.
У маніфесце PersistentVolumeClaim апісваюць патрабаванні да таго дадзеных, які неабходны з дадаткам. У тым ліку:
- памер дыска;
- спосаб доступу: ReadWriteOnce ці ReadWriteMany;
- спасылка на Storage class – у якой сістэме захоўвання дадзеных мы хочам ствараць том.
У маніфесце Storage class захоўваюцца тып і параметры падлучэння да сістэмы захоўвання дадзеных. Яны патрэбныя кублету, каб змантаваць том да сябе на вузел.
У маніфестах PersistentVolume паказваецца Storage class і параметры доступу да канкрэтнага таго (ID тома, шлях, і т. д.).
Ствараючы PVC, Kubernetes глядзіць, тым якога памеру і з якога Storage class запатрабуецца, і падбірае вольны PersistentVolume.
Калі такіх PV няма ў наяўнасці, Kubernetes можа запусціць адмысловую праграму – Provisioner (яе назва паказваюць у Storage class). Гэтая праграма падключаецца да СХД, стварае том патрэбнага памеру, атрымлівае ідэнтыфікатар і стварае ў кластары Kubernetes маніфест PersistentVolume, які злучаецца з PersistentVolumeClaim.
Усё гэта мноства абстракцый дазваляе прыбраць інфармацыю аб тым, з якой СГД працуе дадатак, з узроўня маніфесту прыкладанняў на ўзровень адміністравання.
Усе параметры падлучэння да сістэмы захоўвання дадзеных знаходзяцца ў Storage class, за які адказваюць адміністратары кластара. Усё, што трэба зрабіць пры пераездзе з AWS у Google Cloud, - гэта ў маніфестах прыкладання змяніць назву Storage class у PVC. Persistance Volume для захоўвання дадзеных будуць створаны ў кластары аўтаматычна, з дапамогай праграмы Provisioner.
Спосаб 3. Container Storage Interface
Увесь код, які ўзаемадзейнічае з рознымі сістэмамі захоўвання дадзеных, з'яўляецца часткай ядра Kubernetes. Выпуск выпраўленняў памылак або новага функцыяналу прывязаны да новых рэлізаў, код даводзіцца змяняць для ўсіх падтрымліваемых версій Kubernetes. Усё гэта цяжка падтрымліваць і дабаўляць новы функцыянал.
Каб вырашыць праблему, распрацоўшчыкі з Cloud Foundry, Kubernetes, Mesos і Docker стварылі Container Storage Interface (CSI) – просты уніфікаваны інтэрфейс, які апісвае ўзаемадзеянне сістэмы кіравання кантэйнерамі і спецыяльнага драйвера (CSI Driver), які працуе з канкрэтнай СХД. Увесь код па ўзаемадзеянні з СХД вынеслі з ядра Kubernetes у асобную сістэму.
.
Як правіла, CSI Driver складаецца з двух кампанентаў: Node Plugin і Controller plugin.
Node Plugin запускаецца на кожным вузле і адказвае за мантаванне тамоў і за аперацыі на іх. Controller plugin узаемадзейнічае з СХД: стварае або выдаляе тамы, прызначае правы доступу і т. д.
Пакуль у ядры Kubernetes застаюцца старыя драйверы, але карыстацца імі ўжо не рэкамендуюць і ўсім раяць усталёўваць CSI Driver канкрэтна для той сістэмы, з якой маецца быць працаваць.
Новаўвядзенне можа напалохаць тых, хто ўжо абвык наладжваць захоўванне дадзеных праз Storage class, але насамрэч нічога страшнага не здарылася. Для праграмістаў сапраўды нічога не змяняецца – яны як працавалі толькі з імем Storage class, так і працягнуць. Для адміністратараў дадалася ўстаноўка helm chart і памянялася структура налад. Калі раней налады ўводзіліся ў Storage class напрамую, то зараз іх спачатку трэба задаць у helm chart, а потым ужо ў Storage class. Калі разабрацца, нічога страшнага не здарылася.
Давайце, на прыкладзе, разгледзім якія перавагі можна атрымаць, пяройдучы на падлучэнне СХД Ceph з дапамогай CSI драйвера.
Пры працы з Ceph убудова CSI дае больш магчымасцяў для працы з СХД, чым убудаваныя драйверы.
- Дынамічнае стварэнне кружэлак. Звычайна дыскі RBD выкарыстоўваюцца толькі ў рэжыме RWO, а CSI для Ceph дазваляе выкарыстоўваць іх у рэжыме RWX. Некалькі pod'аў на розных вузлах могуць змантаваць адзін і той жа RDB-дыск да сябе на вузлы і працаваць з імі паралельна. Справядлівасці дзеля, не ўсё так прамяніста - гэты дыск можна падлучыць толькі як блокавая прылада, гэта значыць прыйдзецца адаптаваць прыкладанне пад працу з ім у рэжыме множнага доступу.
- Стварэнне снапшотаў. У кластары Kubernetes можна стварыць маніфест з патрабаваннем стварыць снапшот. Убудова CSI яго ўбачыць і зробіць снапшот з дыска. На яго падставе можна будзе зрабіць або бэкап, або копію PersistentVolume.
- Павелічэнне памеру дыска на СГД і PersistentVolume у кластары Kubernetes.
- Квоты. Убудаваныя ў Kubernetes драйверы CephFS не падтрымліваюць квоты, а свежыя CSI-плагіны са свежым Ceph Nautilus умеюць уключаць квоты на CephFS-часткі.
- Метрыкі. CSI-убудова можа аддаваць у Prometheus мноства метрык пра тое, якія тамы падлучаныя, якія ідуць узаемадзеянні і т. д.
- Topology aware. Дазваляе паказаць у маніфестах, як геаграфічна размеркаваны кластар, і пазбегнуць падлучэння да падах, запушчаным у Лондане сістэмы захоўвання дадзеных, размешчанай у Амстэрдаме.
Як падлучыць Ceph да кластара Kubernetes праз CSI, гледзіце . Таксама можна падпісацца на , які будзе запушчаны 15 кастрычніка
Аўтар артыкула: Сяргей Бондараў, практыкуючы архітэктар Southbridge, Certified Kubernetes Administrator, адзін з распрацоўшчыкаў kubespray.
Трохі Post Scriptum не рэкламы для, а карысці дзеля…
PS Сяргей Бондараў вядзе два інтэнсіўу: абноўлены 28-30 верасня і прасунуты 14-16 кастрычніка.
Крыніца: habr.com