Сутнасць аповяду аб самым папулярным пакетным мэнэджары для Kubernetes можна было б адлюстраваць з дапамогай эмоджы:
- скрынка гэта Helm (гэта самае падыходнае, што ёсць у апошнім рэлізе Emoji);
- замак - бяспека;
- чалавечак - рашэнне праблемы.
На самой жа справе, усё будзе крыху складаней, і аповяд поўны тэхнічных падрабязнасцяў аб тым, як зрабіць Helm бяспечным.
- Коратка, што такое Helm, калі вы не ведалі ці забыліся. Якія праблемы ён вырашае і дзе знаходзіцца ў экасістэме?
- Разгледзім архітэктуру Helm. Ніводная гутарка пра бяспеку і пра тое, як зрабіць прыладу ці рашэнне больш бяспечным, не можа абыйсціся без разумення архітэктуры кампанента.
- Абмяркуем кампаненты Helm.
- Самае актуальнае пытанне – будучыня – новая версія Helm 3.
Усё ў гэтым артыкуле ставіцца да Helm 2. Гэтая версія зараз знаходзіцца ў прадакшэне і, хутчэй за ўсё, менавіта яго вы зараз карыстаецеся, і менавіта ў ім ёсць пагрозы бяспекі.
Аб спікеры: Аляксандр Хаёраў () займаецца распрацоўкай 10 гадоў, дапамагае паляпшаць кантэнт і далучыўся да камітэта . Цяпер працуе ў Chainstack на пазіцыі development lead - гэта гібрыд паміж кіраўніком распрацоўкі і чалавекам, які адказвае за delivery канчатковых рэлізаў. Гэта значыць знаходзіцца на месцы баявых дзеянняў, дзе адбываецца ўсё ад стварэння прадукта да яго эксплуатацыі.
Chainstack - невялікі, актыўна расце, стартап, задачай якога з'яўляецца даць магчымасць кліентам забыцца пра інфраструктуру і складанасці аперавання дэцэнтралізаваных прыкладанняў, каманда распрацоўкі знаходзіцца ў Сінгапуры. Не прасіце Chainstack прадаць або купіць криптовалюту, але прапануйце пагаварыць аб энтерпрайз блокчейн фрэймаўках, і вам з радасцю адкажуць.
шлем
Гэта менеджэр пакетаў (чартаў) для Kubernetes. Самы зразумелы і ўніверсальны спосаб прыносіць прыкладання ў Kubernetes-кластар.
Гаворка, вядома ж, пра больш структурны і прамысловы падыход, чым стварэнне сваіх YAML-маніфестаў і напісанне маленькіх утыліт.
Helm - гэта лепшае, што цяпер ёсць з даступнага і папулярнага.
Чаму Helm? У першую чаргу таму, што ен падтрымліваецца CNCF. Cloud Native - вялікая арганізацыя, з'яўляецца матчынай кампаніяй для праектаў Kubernetes, etcd, Fluentd і іншых.
Іншы важны факт, Helm - вельмі папулярны праект. Калі ў студзені 2019 я толькі задумаў распавесці аб тым, як зрабіць Helm бяспечным, у праекту была тысяча зорачак на GitHub. Да траўня іх стала 12 тысяч.
Многія цікавяцца Helm, таму, нават калі вы да гэтага часу яго не карыстаецеся, вам спатрэбяцца веды адносна яго бяспекі. Бяспека - гэта важна.
Асноўную каманду Helm падтрымлівае Microsoft Azure, і таму гэта даволі стабільны праект у адрозненне ад шматлікіх іншых. Вынахад Helm 3 Alpha 2 у сярэдзіне ліпеня сведчыць аб тым, што над праектам працуе досыць шмат людзей, і ў іх ёсць жаданне і сілы развіваць і паляпшаць Helm.
Helm вырашае некалькі каранёвых праблем кіравання праграмамі ў Kubernetes.
- Пакетаванне прыкладання. Нават дадатак тыпу "Hello, World" на WordPress ужо ўяўляе з сябе некалькі сэрвісаў, і іх хочацца спакаваць разам.
- Упраўленне складанасцю, якая ўзнікае з мэнэджментам гэтых прыкладанняў.
- Жыццёвы цыкл, які не заканчваецца пасля ўстаноўкі або дэплою прыкладання. Яно працягвае жыць, яго трэба абнаўляць, і дапамагае ў гэтым Helm і імкнецца прынесці для гэтага правільныя захады і палітыкі.
Пакетаванне уладкована зразумелай выявай: ёсць метададзеныя ў поўнай адпаведнасці з працай звычайнага пакетнага мэнэджара для Linux, Windows або MacOS. Гэта значыць рэпазітар, залежнасці ад розных пакетаў, метаінфармацыя для прыкладанняў, налады, асаблівасці канфігуравання, індэксаванне інфармацыі і да т.п Усё гэта Helm дазваляе атрымаць і выкарыстоўваць для прыкладанняў.
Упраўленне складанасцю. Калі ў вас шмат аднатыпных прыкладанняў, то патрэбна параметрызацыя. З гэтага выцякаюць шаблоны, але каб не прыдумляць свой спосаб стварэння шаблонаў, можна выкарыстоўваць тое, што Helm прапануе са скрынкі.
Мэнэджмент жыццёвага цыкла прыкладання - на мой погляд, гэта самае цікавае і нявырашанае пытанне. Гэта тое, чаму ў свой час я прыйшоў да Helm. Нам трэба было сачыць за жыццёвым цыклам прыкладання, мы хацелі перанесці свой CI/CD і цыклы прыкладанняў у гэтую парадыгму.
Helm дазваляе:
- кіраваць дэплоямі, уводзіць паняцце кафігурацыі і рэвізіі;
- паспяхова праводзіць rollback;
- выкарыстоўваць хукі на розныя падзеі;
- дадаваць дадатковыя праверкі прыкладанняў і рэагаваць на іх вынікі.
Акрамя таго у Helm ёсць «батарэйкі» - Велізарная колькасць смачных рэчаў, якія можна ўключыць у выглядзе плагінаў, спрасціўшы сваё жыццё. Убудовы можна пісаць самастойна, яны досыць ізаляваныя і не патрабуюць стройнай архітэктуры. Калі вы хочаце нешта рэалізаваць, я рэкамендую зрабіць гэта ў выглядзе плагіна, а потым магчыма ўключыць у upstream.
Helm грунтуецца на трох асноўных канцэпцыях:
- Chart Repo - апісанне і масіў параметрызацыі, магчымай для вашага маніфеста.
- Конфіг Што значыць значэнні, якія будуць ужытыя (тэкст, лікавыя значэнні і да т.п.).
- Адпусціце збірае ў сябе два верхніх кампанента, і разам яны ператвараюцца ў Release. Рэлізы можна версіяваць, тым самым дамагаючыся арганізацыі жыццёвага цыклу: маленькага на момант усталёўкі і буйнага на момант upgrade, downgrade або rollback.
Архітэктура Helm
На схеме канцэптуальна адлюстравана высокаўзроўневая архітэктура Helm.
Нагадаю, што Helm – гэта нешта, што звязана з Kubernetes. Таму нам не абысціся без Kubernetes-кластара (прамавугольнік). Кампанент kube-apiserver знаходзіцца на майстру. Без Helm у нас есць Kubeconfig. Helm прыносіць адну невялікую бінарную, калі можна так назваць, утыліту Helm CLI, якая ўсталёўваецца на кампутар, лэптоп, мэйнфрэйм – на ўсё што заўгодна.
Але гэтага нядосыць. У Helm ёсць серверны кампанент Tiller. Ён прадстаўляе інтарэсы Helm ўнутры кластара, гэта такое ж прыкладанне ўнутры кластара Kubernetes, як і любы іншае.
Наступны кампанент Chart Repo - рэпазітар з чартамі. Ёсць афіцыйны рэпазітар, і можа быць прыватны рэпазітар кампаніі або праекта.
Узаемадзеянне
Разгледзім, як узаемадзейнічаюць кампаненты архітэктуры, калі мы хочам усталяваць дадатак з дапамогай Helm.
- мы гаворым
Helm install, звяртаемся да рэпазітара (Chart Repo) і атрымліваем Helm-чарт.
- Helm-ўтыліта (Helm CLI) узаемадзейнічае з Kubeconfig, для таго каб высветліць да якога кластара звярнуцца.
- Атрымаўшы гэтую інфармацыю, утыліта звяртаецца да Tiller, які знаходзіцца ў нашым кластары, ужо як да дадатку.
- Tiller звяртаецца да Kube-apiserver, каб зрабіць дзеянні ў Kubernetes, стварыць нейкія аб'екты (сэрвісы, поды, рэплікі, сакрэты і г.д.).
Далей мы ўскладнім схему, каб убачыць вектар нападаў, якім можа падвергнуцца ўся архітэктура Helm у цэлым. А потым паспрабуем яе абараніць.
Вектар нападаў
Першае патэнцыйна слабое месца - прывілеяваны API-карыстальнік. У рамках схемы гэта хакер, атрымалы адмінскі доступ да Helm CLI.
Непрывілеяваны API-карыстальнік таксама можа ўяўляць сабой небяспеку, калі знаходзіцца недзе побач. У такога карыстальніка будзе іншы кантэкст, напрыклад, ён можа быць зафіксаваны ў адным namespace кластара ў наладах Kubeconfig.
Найбольш цікавым вектарам атакі можа з'яўляцца працэс, які знаходзіцца ўнутры кластара недзе побач з Tiller і можа да яго звяртацца. Гэта можа быць вэб-сервер або мікрасэрвіс, які бачыць сеткавае асяроддзе кластара.
Экзатычны, але які набірае папулярнасць, варыянт нападу злучаны з Chart Repo. Чарт, створаны нядобрасумленным аўтарам, можа змяшчаць небяспечныя рэсурс, і вы выканаеце яго, прыняўшы на веру. Альбо ён можа падмяніць чарт, які вы спампоўваеце з афіцыйнага рэпазітара, і, напрыклад, стварыць рэсурс у выглядзе палітык і эскалаваць сабе доступ.
Паспрабуем адбіцца ад нападаў са ўсіх гэтых чатырох бакоў і разабрацца, дзе тут праблемы ў архітэктуры Helm, і дзе, магчыма, іх няма.
Узбуйнім схему, дадамо больш элементаў, але захаваем усе базавыя складнікі.
Helm CLI мае зносіны з Chart Repo, узаемадзейнічае з Kubeconfig, праца перадаецца ў кластар у кампанент Tiller.
Tiller прадстаўлены двума аб'ектамі:
- Tiller-deploy svc, які выстаўляе нейкі сэрвіс;
- Tiller-deploy pod (на схеме ў адзіным экзэмпляры ў адной рэпліцы), на якім працуе ўся нагрузка, які звяртаецца да кластара.
Для ўзаемадзеяння выкарыстоўваюцца розныя пратаколы і схемы. З пункту гледжання бяспекі нам найбольш цікавыя:
- Механізм, з дапамогай якога Helm CLI звяртаецца да chart repo: які пратакол, ці ёсць аўтэнтыфікацыя і што з гэтым можна зрабіць.
- Пратакол па якім Helm CLI, выкарыстоўваючы kubectl, мае зносіны з Tiller. Гэта RPC-сервер, усталяваны ўсярэдзіне кластара.
- Сам Tiller даступны для мікрасэрвісаў, якія знаходзяцца ў кластары, і ўзаемадзейнічае з Kube-apiserver.
Абмяркуем усе гэтыя напрамкі па парадку.
РБАК
Бескарысна казаць пра якую-небудзь бяспеку Helm ці іншага сэрвісу ўнутры кластара, калі не ўключаны RBAC.
Здаецца, гэта не сама свежая рэкамендацыя, але ўпэўнены, да гэтага часу многія не ўключылі RBAC нават у прадакшэне, таму што гэта вялікая валтузня і трэба шмат усяго наладзіць. Тым не менш, заклікаю гэта зрабіць.
- сайт-адвакат для RBAC. Там сабрана велізарная колькасць цікавых матэрыялаў, якія дапамогуць наладзіць RBAC, пакажуць, чаму ён добры і як з ім у прынцыпе жыць у прадакшэне.
Паспрабую растлумачыць, як працуе Tiller і RBAC. Tiller працуе ўсярэдзіне кластара пад нейкім сэрвісным акаўнтам. Як правіла, калі не настроены RBAC, гэта будзе суперкарыстальнік. У базавай канфігурацыі Tiller будзе адмінам. Менавіта таму часта кажуць, што Tiller - гэта SSH-тунэль да вашага кластара. У рэчаіснасці гэта так, таму можна выкарыстоўваць асобны спецыялізаваны сэрвісны акаўнт замест Default Service Account на схеме вышэй.
Калі вы ініцыялізуеце Helm, упершыню ўсталёўваеце яго на сервер, то можаце задаць сэрвісны акаўнт з дапамогай --service-account. Гэта дазволіць выкарыстоўваць карыстальніка з мінімальна неабходным наборам правоў. Праўда, давядзецца стварыць такую «гірлянду»: Role і RoleBinding.
Нажаль, Helm не зробіць гэта за вас. Вам ці вашаму адміністратару Kubernetes-кластара трэба загадзя падрыхтаваць набор Role, RoleBinding для service-account, каб перадаць Helm.
Узнікае пытанне - у чым адрозненне паміж Role і ClusterRole? Розніца ў тым, што ClusterRole дзейнічае для ўсіх namespaces, у адрозненне ад звычайных Role і RoleBinding, якія працуюць толькі для спецыялізаванага namespace. Можна наладзіць палітыкі як для ўсяго кластара і ўсіх namespaces, так і персаналізавана для кожнага namespace паасобку.
Варта згадаць, што RBAC дазваляе вырашыць яшчэ адну вялікую праблему. Многія скардзяцца, што Helm, на жаль, не з'яўляецца multitenancy (не падтрымлівае мультыарэнднасць). Калі некалькі каманд спажываюць кластар і выкарыстоўваюць Helm, немагчыма ў прынцыпе наладзіць палітыкі і размежаваць іх доступ у рамках гэтага кластара, таму што ёсць нейкі сэрвісны акаўнт, з-пад якога працуе Helm, і ён стварае з-пад яго ўсе рэсурсы ў кластары, што часам вельмі няёмка. Гэта праўда так - як сам бінарны файл, як працэс, Helm Tiller не мае паняцця аб multitenancy.
Аднак ёсць выдатны спосаб, які дазваляе запусціць Tiller у кластары некалькі разоў. З гэтым няма ніякіх праблем, Tiller можна запусціць у кожным namespace. Тым самым вы можаце скарыстацца RBAC, Kubeconfig як кантэкстам, і абмежаваць доступ да спецыяльнага Helm.
Гэта будзе выглядаць наступным чынам.
Напрыклад, ёсць два Kubeconfig з кантэкстам для розных каманд (два namespace): X Team для каманды распрацоўшчыкаў і кластар адміна. У кластара адміна свой шырокі Tiller, які знаходзіцца ў прасторы Kube-system namespace, адпаведна прасунуты service-account. І асобны namespace для каманды распрацоўшчыкаў, яны змогуць дэплоіць свае сэрвісы ў спецыяльны namespace.
Гэта працоўны падыход, Tiller не настолькі пражэрлівы, каб гэта магло моцна паўплываць на ваш бюджэт. Гэта адно з хуткіх рашэнняў.
Не саромейцеся настройваць асобна Tiller і прадастаўляць Kubeconfig з кантэкстам для каманды, для канкрэтнага распрацоўшчыка або для асяроддзя: Dev, Staging, Production (сумнеўна, што ўсё будзе на адным кластары, аднак, зрабіць так можна).
Працягваючы нашу гісторыю, пераключымся ад RBAC і пагаворым пра ConfigMaps.
ConfigMaps
Helm выкарыстоўвае ConfigMaps у якасці сховішчы дадзеных. Калі мы казалі аб архітэктуры, там нідзе не было базы дадзеных, у якой захоўвалася б інфармацыя аб рэлізах, канфігурацыях, rollbacks і інш. Для гэтага выкарыстоўваецца ConfigMaps.
Асноўная праблема з ConfigMaps вядомая - яны небяспечныя ў прынцыпе, у іх немагчыма захоўваць sensitive-дадзеныя. Гаворка ідзе пра ўсё, што не павінна патрапіць далей сервісу, напрыклад, паролі. Самым натыўным спосабам для Helm зараз з'яўляецца пераход ад выкарыстання ConfigMaps да сакрэтаў.
Гэта робіцца вельмі проста. Перавызначае настройку Tiller і паказваеце, што сховішчам будуць сакрэты. Тады на кожны дэплой вы будзеце атрымліваць не ConfigMap, а сакрэт.
Вы можаце запярэчыць, што самі сакрэты - дзіўная канцэпцыя, і гэта не вельмі бяспечна. Аднак, варта разумець, што гэтым займаюцца самі распрацоўшчыкі Kubernetes. Пачынальна з версіі 1.10, г.зн. даўнавата, ёсць магчымасць, прынамсі, у публічных аблоках падлучаць правільны storage для захоўвання сакрэтаў. Цяпер каманда працуе над тым, каб яшчэ лепш раздаваць доступ да сакрэтаў, асобных падаў ці іншым сутнасцям.
Storage Helm лепш перавесці на сакрэты, а іх у сваю чаргу засцерагчы ад цэнтралізацыі.
Вядома, застанецца ліміт для захоўвання дадзеных у 1 Мбайт. Helm тут выкарыстоўвае etcd як размеркаванае сховішча для ConfigMaps. А там палічылі, што гэта прыдатны чанк дадзеных для рэплікацый і да т.п. З гэтай нагоды ёсць цікавае абмеркаванне на Reddit, рэкамендую знайсці гэтае пацешнае чытво на выходныя або прачытаць выцісканне .
Chart Repos
Чарты найболей сацыяльна ўразлівыя і могуць стаць крыніцай "Man in the middle", асабліва калі выкарыстоўваць стоковое рашэнне. У першую чаргу гаворка ідзе аб рэпазітарах, якія выстаўлены па HTTP.
Вызначана, трэба выстаўляць Helm Repo па HTTPS - гэта лепшы варыянт і варта нядорага.
Звярніце ўвагу на механізм подпісаў чартаў. Тэхналогія простая да бязладдзя. Гэта тое ж самае, чым вы карыстаецеся на GitHub, звычайная PGP машынерыя з публічнымі і прыватнымі ключамі. Наладзьце і будзеце ўпэўненыя, маючы патрэбныя ключы і падпісваючы ўсё, што гэта сапраўды ваш чарт.
Акрамя таго, Helm-кліент падтрымлівае TLS (не ў сэнсе HTTP са боку сервера, а ўзаемны TLS). Вы можаце выкарыстоўваць серверныя і кліенцкія ключы для таго, каб размаўляць. Скажу шчыра, я не выкарыстоўваю такі механізм з-за нялюбасці да ўзаемных сертыфікатаў. У прынцыпе, – асноўны інструмент выстаўлення Helm Repo для Helm 2 – падтрымлівае яшчэ і basic auth. Можна выкарыстоўваць basic auth, калі гэта зручней і спакайней.
Яшчэ ёсць убудова , які дазваляе размяшчаць Chart Repos у Google Cloud Storage. Гэта даволі зручна, выдатна працуе і дастаткова бяспечна, таму што ўтылізуюцца ўсе апісаныя механізмы.
Калі ўлучыць HTTPS ці TLS, выкарыстоўваць mTLS, падлучыць basic auth, каб яшчэ зменшыць рызыкі, атрымаецца бяспечны канал зносін Helm CLI і Chart Repo.
gRPC API
Наступны крок вельмі адказны - засцерагчы Tiller, які знаходзіцца ў кластары і з'яўляецца, з аднаго боку, серверам, з другога боку - сам звяртаецца да іншых кампанентаў і спрабуе прадстаўляцца кімсьці.
Як я ўжо сказаў, Tiller – сэрвіс, які выстаўляе gRPC, Helm-кліент прыходзіць да яго па gRPC. Па змаўчанні, натуральна, TLS выключаны. Навошта гэта зроблена - пытанне дыскусійнае, мне здаецца, каб спрасціць наладу на старце.
Для выпрацоўкі і нават для staging рэкамендую ўключыць TLS на gRPC.
На мой погляд, у адрозненне ад mTLS для чартаў, тут гэта дарэчы і робіцца вельмі проста – генеруеце PQI інфраструктуру, ствараеце сертыфікат, запускаеце Tiller, перадаеце сертыфікат падчас ініцыялізацыі. Пасля гэтага можна выконваць усе Helm-каманды, уяўляючыся згенераваным сертыфікатам і прыватным ключом.
Тым самым вы засцеражэце сябе ад усіх запытаў да Tiller звонку кластара.
Такім чынам, мы засцераглі канал падлучэння да Tiller, ужо абгаварылі RBAC і адрэгулявалі правы Kubernetes apiserver, паменшылі дамен, з якім ён можа ўзаемадзейнічаць.
Абаронены Helm
Паглядзім на фінальную схему. Гэта тая ж самая архітэктура з тымі ж самымі стрэлачкамі.
Усе злучэнні зараз смела можна маляваць зялёным:
- для Chart Repo выкарыстоўваем TLS ці mTLS і basic auth;
- mTLS для Tiller, і ён выстаўлены як gRPC-сэрвіс з TLS, выкарыстоўваем сертыфікаты;
- у кластары выкарыстоўваецца спецыяльны сэрвіс-акаўнт з Role і RoleBinding.
Мы прыкметна засцераглі кластар, але хтосьці разумны сказаў:
"Абсалютна бяспечнае рашэнне можа быць толькі адно – выключаны кампутар, які знаходзіцца ў бетоннай скрынцы і яго ахоўваюць салдаты".
Ёсць розныя спосабы маніпуляцый дадзенымі і знаходжанні новых вектараў нападаў. Аднак я ўпэўнены, што гэтыя рэкамендацыі дазволяць рэалізаваць базавы прамысловы стандарт бяспекі.
бонус
Гэтая частка не адносіцца напрамую да бяспекі, але таксама будзе карысная. Пакажу некаторыя цікавыя рэчы, пра якія нямногія ведаюць. Напрыклад, як шукаць чарты - афіцыйныя і неафіцыйныя.
У рэпазітары зараз каля 300 чартаў і два стрыму: stable і incubator. Той, хто контрибьютит, выдатна ведае, як цяжка патрапіць з incubator у stable, і як лёгка са stable вылецець. Аднак, гэта не лепшы інструмент, каб шукаць чарты для Prometheus і ўсяго, што вам падабаецца, па адной простай прычыне - гэта не партал, дзе зручна шукаць пакеты.
Але ёсць сэрвіс , з дапамогай якога знаходзіць чарты значна зручней. Самае галоўнае, там нашмат больш вонкавых рэпазітараў і даступна амаль 800 чаротаў. Плюс, вы можаце падлучыць свой рэпазітар, калі па нейкіх чынніках не жадаеце адпраўляць свае чарты ў stable.
Паспрабуйце hub.helm.sh і давайце разам яго разьвіваць. Гэты сэрвіс пад Helm-праектам, і вы можаце кантрыб'юціць нават у яго UI, калі вы франтэндэр і хочаце проста палепшыць знешні выгляд.
Яшчэ хачу звярнуць вашу ўвагу на Open Service Broker API integration. Гучыць грувастка і незразумела, але вырашае задачы, з якім усе сутыкаюцца. Растлумачу на простым прыкладзе.
Ёсць Kubernetes-кластар, у якім мы хочам запусціць класічны дадатак - WordPress. Як правіла, для поўнай функцыянальнасці патрэбна база даных. Ёсць шмат розных рашэнняў, напрыклад, можна запусціць свой statefull-сэрвіс. Гэта не вельмі зручна, але шмат хто так робіць.
Іншыя, напрыклад, мы ў Chainstack, выкарыстоўваюць managed базы дадзеных, напрыклад, MySQL ці PostgreSQL, для сервераў. Таму ў нас БД знаходзяцца недзе ў воблаку.
Але ўзнікае праблема: трэба звязаць наш сэрвіс з базай дадзеных, стварыць flavor базы дадзеных, перадаць credential і неяк ім кіраваць. Усё гэта звычайна робіцца ўручную сістэмным адміністратарам ці распрацоўшчыкам. І няма ніякай праблемы, калі прыкладанняў мала. Калі іх шмат, патрэбен камбайн. Такі камбайн ёсць - гэта Service Broker. Ён дазваляе выкарыстоўваць адмысловую ўбудову да кластара публічнага аблокі і заказваць рэсурсы ў правайдэра праз Broker, як быццам гэта API. Для гэтага можна выкарыстоўваць натыўныя сродкі Kubernetes.
Гэта проста. Можна запытаць, напрыклад, Managed MySQL у Azure з базавым tier (гэта можна наладзіць). З выкарыстаннем API Azure база будзе створана і падрыхтавана да выкарыстання. Вам не спатрэбіцца ў гэта ўмешвацца, за гэта адказвае плягін. Напрыклад, OSBA (убудова Azure) верне credential у сэрвіс, перадасць гэта Helm. Вы зможаце выкарыстоўваць WordPress з хмарным MySQL, наогул не займацца managed базамі дадзеных і не парыцца аб statefull-сэрвісах усярэдзіне.
Можна сказаць, што Helm выступае клеем, які з аднаго боку дазваляе дэплоіць сэрвісы, а з другога – спажываць рэсурсы хмарных правайдэраў.
Можна напісаць сваю ўбудову і выкарыстоўваць усю гэтую гісторыю on-premise. Тады ў вас проста будзе свой убудова да карпаратыўнага Cloud-правайдэру. Я раю паспрабаваць такі падыход, асабліва калі ў вас вялікі маштаб і вы хочаце хутка разгарнуць dev, staging ці ўсю інфраструктуру пад фічу. Гэта спросціць жыцце вашым operations або DevOps.
Яшчэ адна знаходка, якую я ўжо згадваў - гэта убудова helm-gcs, які дазваляе выкарыстоўваць Google-buckets (аб'ектнае сховішча), каб захоўваць Helm-чарты.
Трэба ўсяго чатыры каманды, каб пачаць яго выкарыстоўваць:
- усталяваць убудову;
- ініцыяваць яго;
- задаць шлях да bucket, які знаходзіцца ў gcp;
- апублікаваць чарты стандартным спосабам.
Хараство ў тым, што будзе выкарыстоўвацца натыўны спосаб gcp для аўтарызацыі. Вы можаце выкарыстоўваць сэрвісны акаўнт, акаўнт распрацоўніка - усё, што заўгодна. Гэта вельмі зручна і нічога не варта ў эксплуатацыі. Калі вы, як і я, прапагандуеце opsless-філасофію, тое гэта будзе вельмі зручна, асабліва для невялікіх каманд.
альтэрнатывы
Helm - не адзінае рашэнне для кіравання сэрвісамі. Да яго шмат пытанняў, мусіць, таму так хутка з'явілася трэцяя версія. Канешне, ёсць альтэрнатывы.
Гэта могуць быць як спецыялізаваныя рашэнні, напрыклад, Ksonnet ці Metaparticle. Вы можаце выкарыстоўваць свае класічныя сродкі кіравання інфраструктурай (Ansible, Terraform, Chef і інш) для тых жа мэт, пра якія я казаў.
Нарэшце, ёсць рашэнне , папулярнасць якога расце.
Operator Framework – галоўная альтэрнатыва Helm, на якую варта звярнуць увагу.
Яно больш натыўна для CNCF і Kubernetes, але парог уваходжання нашмат вышэй, трэба больш праграмаваць і менш апісваць маніфесты.
Ёсць розныя addons, такія, як Draft, Scaffold. Яны моцна палягчаюць жыццё, напрыклад, распрацоўнікам спрашчаюць цыкл адпраўкі і запуску Helm для дэплою тэставага асяроддзя. Я б назваў іх пашыральнікамі магчымасьцяў.
Вось наглядны графік аб тым, дзе што знаходзіцца.
Па восі абсцыс ўзровень вашага асабістага кантролю над тым, што адбываецца, па восі ардынат - узровень натыўнасці Kubernetes. Helm версіі 2 знаходзіцца недзе пасярэдзіне. У версіі 3 не каласальна, але палепшаны і кантроль і ўзровень натыўнасці. Рашэнні ўзроўню Ksonnet усёткі саступаюць нават Helm 2. Аднак на іх варта паглядзець, каб ведаць, што яшчэ ёсць у гэтым свеце. Вядома, ваш менеджэр канфігурацый будзе ў вас пад кантролем, але абсалютна не націўны для Kubernetes.
Operator Framework абсалютна націвен для Kubernetes і дазваляе кіраваць ім нашмат элегантней і скрупулёзней (але памятаем пра ўзровень уваходжання). Хутчэй, гэта падыдзе для спецыялізаванага прыкладання і стварэнні для яго мэнэджменту, чым масавага камбайна па пакаванні велізарнай колькасці прыкладанняў з дапамогай Helm.
Пашыральнікі проста ледзь паляпшаюць кантроль, дапаўняюць workflow ці зразаюць куты CI/CD pipelines.
Будучыня Helm
Добрая навіна ў тым, што з'яўляецца Helm 3. Ужо выйшаў рэліз альфа-версіі Helm 3.0.0-alpha.2, можна паспрабаваць. Ён дастаткова стабільны, але функцыянальнасць пакуль абмежавана.
Навошта патрэбен Helm 3? У першую чаргу гэта гісторыя пра знікненне Tiller, як кампанента. Гэта, як вы ўжо разумееце, вялізны крок наперад, таму што з пункту гледжання бяспекі архітэктуры ўсё спрашчаецца.
Калі ствараўся Helm 2, а гэта было ў часы Kubernetes 1.8 ці нават раней, шматлікія канцэпцыі былі няспелыя. Напрыклад, канцэпцыя CRD зараз актыўна ўкараняецца, і Helm будзе выкарыстоўваць CRD, Каб захоўваць структуры. Стане магчымым выкарыстоўваць толькі кліент і не трымаць серверную частку. Адпаведна, выкарыстоўваць натыўныя каманды Kubernetes для працы са структурамі і рэсурсамі. Гэта вялізны крок наперад.
з'явіцца падтрымка натыўных рэпазітараў OCI (Open Container Initiative). Гэта велізарная ініцыятыва, і Helm яна цікавая ў першую чаргу для таго, каб размяшчаць свае чарты. Даходзіць да таго, што, напрыклад, Docker Hub падтрымлівае шматлікія стандарты OCI. Я не загадваю, але магчыма, класічныя правайдэры Docker-рэпазітароў пачнуць даваць магчымасць размяшчаць вам свае Helm-чарты.
Спрэчная для мяне гісторыя - гэта падтрымка Lua, як templating engine для напісання скрыптоў. Я не вялікі фанат Lua, але гэта будзе цалкам апцыянальнай магчымасць. Я 3 разы гэта праверыў - выкарыстанне Lua будзе не абавязкова. Таму той, хто хоча зможа выкарыстоўваць Lua, той, каму падабаецца Go - далучайцеся да нашага вялізнага лагера і выкарыстоўвайце go-tmpl для гэтага.
Нарэшце тое, чаго мне сапраўды не хапала - гэта з'яўленне схемы і валідацыя тыпаў дадзеных. Больш не будзе праблем з int або string, не трэба будзе абгортваць нуль у падвойныя двукоссі. Зьявіцца JSONS-схема, якая дазволіць відавочна гэта апісаць для values.
Будзе вельмі моцна перапрацавана event-driven model. Яна ўжо канцэптуальна апісана. Паглядзіце ў галінку Helm 3, і ўбачыце, як шмат было дададзена падзей і хукаў і іншага, што моцна спросціць і, з іншага боку, дадасць кантролю над працэсамі дэплою і рэакцый па іх.
Helm 3 будзе прасцей, бяспечней і цікавей не таму, што мы не каханы Helm 2, а таму што Kubernetes становіцца больш прасунутым. Адпаведна, Helm можа выкарыстоўваць напрацоўкі Kubernetes і ствараць на ім выдатныя мэнэджары для Kubernetes.
Яшчэ адна добрая навіна ў тым, што на Аляксандр Хаёраў раскажа, Нагадаем, канферэнцыя па інтэграцыі працэсаў распрацоўкі, тэсціравання і эксплуатацыі пройдзе ў Маскве 30 верасня і 1 кастрычніка. Да 20 жніўня яшчэ можна і расказаць аб сваім вопыце рашэння задач DevOps-падыходу.
За чэкпойнтамі канферэнцыі і навінамі сочыце ў и .
Крыніца: habr.com