Kubernetes үчүн эң популярдуу пакет менеджери жөнүндөгү окуянын маңызы эмодзилерди колдонуу менен сүрөттөлүшү мүмкүн:
- кутуча - Helm (бул акыркы Эмодзи релизине эң жакын нерсе);
- кулпу - коопсуздук;
- кичинекей адам - маселенин чечими.
Чынында, баары бир аз татаалыраак болот жана окуя техникалык деталдарга толгон Helm кантип коопсуз кылуу керек.
- Эгер сиз билбесеңиз же унутуп калсаңыз, Helm деген эмне экенин кыскача. Кандай көйгөйлөрдү чечет жана экосистеманын кайсы жеринде жайгашкан.
- Helm архитектурасын карап көрөлү. Компоненттин архитектурасын түшүнбөй туруп, коопсуздук жана куралды же чечимди кантип коопсуз кылуу керектиги жөнүндө эч кандай сүйлөшүү бүтпөйт.
- Келгиле, Helm компоненттерин талкуулайлы.
- Эң курч суроо - бул келечек - Helm 3тин жаңы версиясы.
Бул макаладагы бардыгы Helm 2ге тиешелүү. Бул версия учурда өндүрүштө жана сиз азыр колдонуп жаткан версия болуп саналат жана бул коопсуздук тобокелдиктерин камтыган версия.
спикер жөнүндө: Александр Хайёров () мазмунду жакшыртууга жардам берип, 10 жылдан бери өнүгүп келе жатат жана комитетке кирди . Азыр ал Chainstackте өнүктүрүү боюнча жетекчи катары иштейт - бул иштеп чыгуу менеджери менен акыркы релиздерди жеткирүү үчүн жооптуу адамдын ортосундагы гибрид. Башкача айтканда, ал согуш талаасында жайгашкан, ал жерде продукцияны жаратуудан баштап, анын иштөөсүнө чейин баары болот.
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 колдонмосун башкаруунун бир нече түпкү көйгөйлөрүн чечет.
- Колдонмонун таңгагы. Ал тургай, WordPressтеги "Салам, дүйнө" сыяктуу тиркеме бир нече кызматтардан турат жана сиз аларды чогуу топтогуңуз келет.
- Бул колдонмолорду башкаруу менен коштолгон татаалдыкты башкаруу.
- Колдонмо орнотулгандан же жайылтылгандан кийин бүтпөй турган жашоо цикли. Ал жашоосун улантууда, аны жаңыртуу керек жана Хелм буга жардам берет жана бул үчүн туура чараларды жана саясаттарды алып келүүгө аракет кылат.
Каптоо ал так түрдө уюштурулган: Linux, Windows же MacOS үчүн кадимки пакет менеджеринин ишине толук ылайык келген метаберилиштер бар. Башкача айтканда, репозиторий, ар кандай пакеттерге көз карандылыктар, тиркемелер үчүн мета маалымат, орнотуулар, конфигурация функциялары, маалыматты индекстөө ж.б.
Татаалдуулукту башкаруу. Эгер сизде бир типтеги көптөгөн тиркемелер болсо, анда параметрлештирүү керек. Калыптар ушундан келип чыгат, бирок шаблондорду түзүүнүн өз ыкмасын ойлоп таппаш үчүн, Helm кутудан сунуштаган нерселерди колдонсоңуз болот.
Колдонмонун жашоо циклин башкаруу - менин оюмча, бул эң кызыктуу жана чечилбеген суроо. Ошон үчүн мен кайра күнү Хельмге келдим. Колдонмонун жашоо циклине көз салышыбыз керек жана CI/CD жана колдонмо циклдерибизди ушул парадигмага жылдыргыбыз келди.
Helm сизге төмөнкүлөргө мүмкүндүк берет:
- жайгаштырууларды башкаруу, конфигурациялоо жана кайра карап чыгуу түшүнүгүн киргизет;
- ийгиликтүү артка кайтаруу;
- ар кандай окуялар үчүн илгичтерди колдонуу;
- кошумча өтүнмө текшерүүлөрдү кошуу жана алардын натыйжаларына жооп берүү.
Андан тышкары Рулда "батареялар" бар - жашооңузду жөнөкөйлөтүп, плагиндер түрүндө камтыла турган көптөгөн даамдуу нерселердин саны. Плагиндерди өз алдынча жазууга болот, алар бир топ обочолонгон жана гармониялуу архитектураны талап кылбайт. Эгер сиз бир нерсени ишке ашырууну кааласаңыз, мен аны плагин катары жасоону сунуштайм, анан, балким, аны агымга кошууну сунуштайм.
Helm үч негизги түшүнүккө негизделген:
- Диаграмма репо — манифестиңиз үчүн мүмкүн болгон параметрлердин сүрөттөлүшү жана массиви.
- Config — башкача айтканда, колдонула турган баалуулуктар (текст, сандык маанилер, ж.б.).
- чыгаруу эки үстүнкү компоненттерди чогултат, жана алар чогуу Release айланат. Релиздерди версиялоого болот, ошону менен уюшкан жашоо циклине жетишүү мүмкүн: орнотуу учурунда кичинекей жана жаңыртуу, төмөндөтүү же артка кайтаруу учурунда чоң.
Руль архитектурасы
Диаграмма концептуалдык жактан Хельмдин жогорку деңгээлдеги архитектурасын чагылдырат.
Хелм 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 колдонуучусу жакын жерде болсо да коркунуч жаратышы мүмкүн. Мындай колдонуучу башка контекстке ээ болот, мисалы, ал Kubeconfig жөндөөлөрүндө бир кластердик аттар мейкиндигинде бекитилиши мүмкүн.
Эң кызыктуу чабуул вектору Тиллерге жакын жердеги кластердин ичинде жайгашкан жана ага кире алган процесс болушу мүмкүн. Бул кластердин тармактык чөйрөсүн көргөн веб-сервер же микросервис болушу мүмкүн.
Экзотикалык, бирок барган сайын популярдуу болгон чабуул варианты Chart Repo камтыйт. Ыймансыз автор тарабынан түзүлгөн диаграмма кооптуу ресурстарды камтышы мүмкүн жана сиз аны ишеним менен толуктайсыз. Же ал сиз расмий репозиторийден жүктөп алган диаграмманы алмаштырып, мисалы, саясат түрүндөгү ресурсту түзүп, анын жеткиликтүүлүгүн жогорулата алат.
Келгиле, ушул төрт тараптан болгон чабуулдарды токтотууга аракет кылалы жана Helm архитектурасында кайсы жерде көйгөйлөр бар жана кайсы жерде, балким, жок экенин аныктайлы.
Диаграмманы чоңойтуп, көбүрөөк элементтерди кошолу, бирок бардык негизги компоненттерди сактайлы.
Helm CLI Chart Repo менен байланышат, Kubeconfig менен иштешет жана иш кластерге Tiller компонентине өткөрүлөт.
Тиллер эки объект менен көрсөтүлөт:
- Белгилүү бир кызматты ашкерелеген Tiller-deploy svc;
- Кластерге кире турган, бүт жүктөм иштей турган (диаграммада бир репликадагы бир нускада) подключены жайгаштыруу.
Өз ара аракеттенүү үчүн ар кандай протоколдор жана схемалар колдонулат. Коопсуздук көз карашынан алганда, бизди эң кызыкдар:
- Helm CLI диаграмма репосуна кирүү механизми: кандай протокол, аутентификация барбы жана аны менен эмне кылса болот.
- Helm CLI, kubectl колдонуп, Тиллер менен баарлашкан протокол. Бул кластердин ичинде орнотулган RPC сервери.
- Tiller өзү кластерде жашаган жана Kube-аписервер менен иштешкен микросервистерге жеткиликтүү.
Келгиле, бул тармактардын баарын ирети менен талкуулайлы.
RBAC
RBAC иштетилмейинче, Helm же кластердин ичиндеги башка кызмат үчүн коопсуздук жөнүндө сөз кылуунун эч кандай мааниси жок.
Бул акыркы сунуш эмес окшойт, бирок мен көптөгөн адамдар RBACти өндүрүштө дагы иштете электигине ишенем, анткени бул көп ызы-чуу жана көп нерсени конфигурациялоо керек. Бирок, мен сени муну кылууга чакырам.
— RBAC сайтынын юристи. Бул RBAC орнотууга жардам бере турган көп сандагы кызыктуу материалдарды камтыйт, эмне үчүн ал жакшы жана аны менен өндүрүштө кантип жашаш керек.
Мен Tiller жана RBAC кантип иштээрин түшүндүрүүгө аракет кылам. Тиллер кластердин ичинде белгилүү бир кызмат эсеби боюнча иштейт. Адатта, RBAC конфигурацияланбаса, бул супер колдонуучу болот. Негизги конфигурацияда Тиллер администратор болот. Ошондуктан Tiller сиздин кластерге SSH туннели деп көп айтылат. Чынында, бул чындык, андыктан сиз жогорудагы диаграммадагы Демейки Кызмат Каттоо эсебинин ордуна өзүнчө атайын кызмат эсебин колдоно аласыз.
Helmди инициализациялоодо жана аны серверге биринчи жолу орнотуп жатканда, сиз кызмат эсебин колдонуу менен орното аласыз --service-account. Бул сизге минималдуу талап кылынган укуктар топтому менен колдонуучуну колдонууга мүмкүндүк берет. Ырас, сиз мындай "гирляндияны" түзүшүңүз керек болот: Role and RoleBinding.
Тилекке каршы, Helm муну сиз үчүн кылбайт. Сиз же Kubernetes кластериңиздин администраторуңуз Helm'ден өтүү үчүн кызмат эсеби үчүн Roles жана RoleBindings топтомун алдын ала даярдашыңыз керек.
Суроо туулат - Role жана ClusterRole ортосунда кандай айырма бар? Айырмачылыгы, ClusterRole бардык аттар мейкиндиги үчүн иштейт, кадимки Roles жана RoleBindings айырмаланып, адистештирилген аттар мейкиндиги үчүн гана иштейт. Сиз бүткүл кластер жана бардык аттар мейкиндиктери үчүн саясаттарды конфигурациялай аласыз же ар бир аттар мейкиндиги үчүн жекечелештире аласыз.
Белгилей кетсек, RBAC дагы бир чоң маселени чечет. Көптөгөн адамдар Helm, тилекке каршы, көп ижаралык эмес деп даттанышат (көп ижарачылыкты колдобойт). Эгерде бир нече командалар кластерди колдонсо жана Helm колдонсо, бул кластердин ичинде саясаттарды түзүү жана алардын кирүү мүмкүнчүлүгүн чектөө негизинен мүмкүн эмес, анткени Helm иштеген белгилүү бир кызмат эсеби бар жана ал кластердеги бардык ресурстарды анын астынан жаратат. , бул кээде абдан ыңгайсыз. Бул чындык - бинардык файлдын өзү сыяктуу, процесс сыяктуу, Helm Tiller көп ижара түшүнүгү жок.
Бирок, бир кластерде бир нече жолу Tiller иштетүүгө мүмкүндүк берген сонун жолу бар. Муну менен эч кандай көйгөй жок, Tiller ар бир мейкиндикте ишке киргизилиши мүмкүн. Ошентип, контекст катары RBAC, Kubeconfig колдоно аласыз жана атайын Helmге кирүү мүмкүнчүлүгүн чектей аласыз.
Бул ушундай болот.
Мисалы, ар кандай командалар үчүн контексти бар эки Kubeconfig бар (эки аттар мейкиндиги): Өнүктүрүү тобу үчүн X командасы жана администратор кластери. Администратордук кластердин өзүнүн кең Tiller бар, ал Kube тутумунун аттар мейкиндигинде, тиешелүү түрдө өркүндөтүлгөн кызмат эсебинде жайгашкан. Жана иштеп чыгуу тобу үчүн өзүнчө аттар мейкиндиги, алар өз кызматтарын атайын аттар мейкиндигине жайгаштыра алышат.
Бул ишке жарамдуу ыкма, Тиллер ушунчалык күчкө муктаж эмес, бул сиздин бюджетиңизге чоң таасирин тийгизет. Бул тез чечимдердин бири болуп саналат.
Tilleri өзүнчө конфигурациялоодон тартынбаңыз жана Kubeconfigге команда, белгилүү бир иштеп чыгуучу же чөйрө үчүн контекст менен камсыз кылыңыз: Dev, Staging, Production (баары бир кластерде болору күмөндүү, бирок муну жасоого болот).
Окуябызды улантып, келгиле, RBACдан которулуп, ConfigMaps жөнүндө сүйлөшөлү.
ConfigMaps
Helm маалымат кампасы катары ConfigMaps колдонот. Биз архитектура жөнүндө сөз кылганда, эч жерде релиздер, конфигурациялар, артка кайтаруулар ж.
ConfigMaps менен негизги көйгөй белгилүү - алар негизинен кооптуу; купуя маалыматтарды сактоо мүмкүн эмес. Биз кызматтын чегинен чыкпашы керек болгон нерселердин бардыгы жөнүндө айтып жатабыз, мисалы, сырсөздөр. Азыр Helm үчүн эң негизги жолу - ConfigMaps колдонуудан сырларга өтүү.
Бул абдан жөнөкөй жасалат. Тиллер жөндөөсүн жокко чыгарып, сактагыч сыр болуп калаарын белгилеңиз. Андан кийин ар бир жайгаштыруу үчүн сиз ConfigMap эмес, сырды аласыз.
Сиз сырлар кызыктай түшүнүк жана өтө коопсуз эмес деп талаша аласыз. Бирок, муну Kubernetes иштеп чыгуучулары өздөрү жасап жатканын түшүнүү керек. 1.10 версиясынан баштап, б.а. Бир топ убакыттан бери, жок эле дегенде, коомдук булуттарда, сырларды сактоо үчүн туура сактагычты туташтыруу мүмкүн болду. Команда азыр сырларга, жеке подъезддерге же башка объекттерге кирүү мүмкүнчүлүгүн жакшыраак жайылтуу жолдорунун үстүндө иштеп жатат.
Storage Helm'ди сырларга өткөрүп берүү жакшыраак жана алар өз кезегинде борборлоштурулган.
Албетте кала берет маалымат сактоо чеги 1 МБ. Helm бул жерде ConfigMaps үчүн бөлүштүрүлгөн сактагыч катары etcd колдонот. Жана алар бул репликациялоо үчүн ылайыктуу маалымат бөлүгү деп эсептешкен, ж.б. Бул тууралуу Redditте кызыктуу талкуу жүрүп жатат, мен дем алыш күндөрү бул күлкүлүү окууну табууну же үзүндүнү окууну сунуштайм .
Chart Repos
Диаграммалар социалдык жактан эң аялуу болуп саналат жана "Ортодогу адам" булагы болуп калышы мүмкүн, өзгөчө, эгерде сиз биржа чечимди колдонсоңуз. Биринчиден, биз HTTP аркылуу ачылган репозиторийлер жөнүндө сөз болуп жатат.
Сиз HTTPS аркылуу Helm Repo ачыкка чыгарышыңыз керек - бул эң жакшы вариант жана арзан.
сак болгула диаграммага кол коюу механизми. Технология тозок сыяктуу жөнөкөй. Бул GitHub, жалпы жана купуя ачкычтары бар кадимки PGP машинасында колдонгон нерсе. Керектүү ачкычтарга ээ болуп, бардыгына кол коюп, бул чындап эле сиздин диаграммаңыз экенине ынаныңыз.
Мындан тышкары, Helm кардары TLSти колдойт (сервер тараптагы HTTP маанисинде эмес, өз ара TLS). Байланыш үчүн сервер жана кардар ачкычтарын колдоно аласыз. Чынын айтсам, мен мындай механизмди колдонбойм, анткени мен өз ара сертификаттарды жактырбайм. Негизинен, - Helm 2 үчүн Helm Repo орнотуу үчүн негизги курал - ошондой эле негизги аутентификацияны колдойт. Эгер ал ыңгайлуураак жана тынчыраак болсо, сиз негизги аутентификацияны колдоно аласыз.
плагин да бар , бул сизге Google Cloud Storageде Диаграмма репосун өткөрүүгө мүмкүндүк берет. Бул абдан ыңгайлуу, сонун иштейт жана абдан коопсуз, анткени бардык сүрөттөлгөн механизмдер кайра иштетилет.
Эгер сиз HTTPS же TLS иштетсеңиз, mTLS колдонсоңуз жана тобокелдиктерди андан ары азайтуу үчүн негизги аутентификацияны иштетсеңиз, Helm CLI жана Chart Repo менен коопсуз байланыш каналына ээ болосуз.
gRPC API
Кийинки кадам абдан маанилүү - кластерде жайгашкан жана бир жагынан сервер болуп саналган Tilleri камсыз кылуу, экинчи жагынан, ал өзү башка компоненттерге кирип, кимдир бирөө болуп көрүнүүгө аракет кылат.
Мен буга чейин айткандай, Tiller бул gRPC ачкан кызмат, Helm кардары ага gRPC аркылуу келет. Демейки боюнча, албетте, TLS өчүрүлгөн. Бул эмне үчүн жасалганы талаштуу суроо, мен башында орнотууну жөнөкөйлөштүрүү керек окшойт.
Өндүрүү жана ал тургай сахналаштыруу үчүн мен gRPCде TLS иштетүүнү сунуштайм.
Менин оюмча, диаграммалар үчүн mTLSден айырмаланып, бул жерде ылайыктуу жана абдан жөнөкөй - PQI инфраструктурасын түзүү, сертификат түзүү, Tilleri ишке киргизүү, инициализация учурунда сертификатты өткөрүп берүү. Андан кийин, сиз түзүлгөн күбөлүк жана жеке ачкыч менен таанышып, бардык Helm буйруктарын аткара аласыз.
Ушундай жол менен сиз өзүңүздү кластердин сыртынан Tillerге болгон бардык суроо-талаптардан коргойсуз.
Ошентип, биз Тиллерге туташуу каналын камсыздадык, биз RBACти талкууладык жана Kubernetes аписерверинин укуктарын тууралап, ал өз ара аракеттене турган доменди азайттык.
Protected Helm
Келгиле, акыркы диаграмманы карап көрөлү. Бул ошол эле жебелер менен бир эле архитектура.
Бардык байланыштар эми жашыл түс менен коопсуз тартылышы мүмкүн:
- Chart Repo үчүн биз TLS же mTLS жана негизги аутентификацияны колдонобуз;
- Tiller үчүн mTLS жана ал TLS менен gRPC кызматы катары ачылат, биз сертификаттарды колдонобуз;
- кластер Role жана RoleBinding менен атайын кызмат эсебин колдонот.
Биз кластерди кыйла камсыз кылдык, бирок кимдир бирөө акылдуу айтты:
"Бир гана таптакыр коопсуз чечим болушу мүмкүн - бетон кутуда жайгашкан жана аскерлер кайтарган өчүрүлгөн компьютер."
Маалыматтарды манипуляциялоо жана жаңы чабуул векторлорун табуу үчүн ар кандай жолдор бар. Бирок, бул сунуштар коопсуздуктун негизги тармактык стандартына жетет деп ишенем.
премия
Бул бөлүгү коопсуздукка түздөн-түз байланыштуу эмес, бирок ошондой эле пайдалуу болот. Мен сизге аз адамдар билген кызыктуу нерселерди көрсөтөм. Мисалы, диаграммаларды кантип издөө керек - расмий жана расмий эмес.
Репозиторийде Азыр 300гө жакын диаграммалар жана эки агым бар: туруктуу жана инкубатор. Салым кошкон адам инкубатордон стабилге өтүү канчалык кыйын экенин жана сарайдан учуп кетүү канчалык оңой экенин жакшы билет. Бирок, бул Prometheus үчүн диаграммаларды издөө үчүн эң жакшы курал эмес жана сизге жаккан башка нерсе, бир жөнөкөй себеп менен - бул сиз пакеттерди ыңгайлуу издей турган портал эмес.
Бирок кызматы бар , бул диаграммаларды табуу үчүн бир топ ыңгайлуу кылат. Эң негизгиси, дагы көптөгөн тышкы репозиторийлер жана дээрлик 800 тумарлар бар. Мындан тышкары, кандайдыр бир себептерден улам диаграммаларыңызды туруктууга жөнөткүңүз келбесе, репозиторийиңизди туташтыра аласыз.
hub.helm.sh колдонуп көрүңүз жана аны чогуу өнүктүрөлү. Бул кызмат Helm долбоорунун алкагында, эгер сиз алдыңкы иштеп чыгуучу болсоңуз жана жөн гана көрүнүштү жакшырткыңыз келсе, анын UIге салым кошо аласыз.
Мен дагы сиздердин көңүлүңүздү бургум келет Open Service Broker API интеграциясы. Бул оор жана түшүнүксүз угулат, бирок ал ар бир адам туш болгон көйгөйлөрдү чечет. Жөнөкөй мисал менен түшүндүрүп берейин.
Kubernetes кластери бар, анда биз классикалык тиркемени иштеткибиз келет - WordPress. Жалпысынан, толук иштеши үчүн маалымат базасы керек. Көптөгөн ар кандай чечимдер бар, мисалы, сиз өзүңүздүн мамлекеттик кызматыңызды ишке киргизе аласыз. Бул абдан ыңгайлуу эмес, бирок көп адамдар муну жасайт.
Башкалар, биз сыяктуу Chainstack, серверлери үчүн MySQL же PostgreSQL сыяктуу башкарылуучу маалымат базаларын колдонушат. Ошондуктан биздин маалымат базалары булуттун бир жеринде жайгашкан.
Бирок маселе келип чыгат: биз кызматыбызды маалымат базасы менен туташтырышыбыз керек, маалымат базасынын даамын түзүп, ишеним грамотасын өткөрүп, кандайдыр бир жол менен башкаруубуз керек. Мунун баары адатта система администратору же иштеп чыгуучу тарабынан кол менен жасалат. Ал эми арыздар аз болгондо эч кандай көйгөй болбойт. Алар көп болгондо комбайн керек. Мындай комбайн бар - бул Service Broker. Бул жалпыга ачык булут кластери үчүн атайын плагинди колдонууга жана API сыяктуу эле Брокер аркылуу провайдерден ресурстарга заказ кылууга мүмкүндүк берет. Бул үчүн, сиз жергиликтүү Kubernetes куралдарын колдоно аласыз.
Бул абдан жөнөкөй. Сиз, мисалы, Azure ичинде башкарылуучу MySQLди базалык деңгээли менен сурасаңыз болот (бул конфигурацияланышы мүмкүн). Azure API колдонуу менен маалымат базасы түзүлөт жана колдонууга даярдалат. Буга кийлигишүүнүн кереги жок, бул үчүн плагин жооптуу. Мисалы, OSBA (Azure плагини) кызматка ишеним грамотасын кайтарып берет жана аны Helmге өткөрүп берет. Сиз WordPressти булут MySQL менен колдоно аласыз, башкарылуучу маалымат базалары менен такыр алектенбейсиз жана ичиндеги мамлекеттик кызматтар жөнүндө кабатырланбайсыз.
Биз Helm клей катары иштейт деп айта алабыз, ал бир жагынан кызматтарды жайылтууга мүмкүндүк берет, ал эми экинчи жагынан булут провайдерлеринин ресурстарын керектейт.
Сиз өзүңүздүн плагиниңизди жазып, бул окуяны жеринде колдоно аласыз. Ошондо сизде жөн гана корпоративдик Cloud провайдери үчүн өзүңүздүн плагиниңиз болот. Мен бул ыкманы сынап көрүүнү сунуштайм, өзгөчө, эгер сизде чоң масштаб болсо жана бир функция үчүн иштеп чыгууну, инфраструктураны же бүтүндөй инфраструктураны тез жайгаштыргыңыз келсе. Бул сиздин операцияларыңыз же DevOps үчүн жашоону жеңилдетет.
Мен айтып өткөн дагы бир табылга helm-gcs плагини, бул сизге Helm диаграммаларын сактоо үчүн Google-чакаларды (объект сактагыч) колдонууга мүмкүндүк берет.
Аны колдонуу үчүн сизге төрт гана буйрук керек:
- плагинди орнотуу;
- аны баштоо;
- gcp жайгашкан чака жолду коюу;
- стандарттуу түрдө диаграммаларды жарыялоо.
Сулуулук жергиликтүү gcp ыкмасы авторизациялоо үчүн колдонулат. Кызмат каттоо эсебин, иштеп чыгуучу каттоо эсебин, каалаганыңызды колдоно аласыз. Бул абдан ыңгайлуу жана иштетүү үчүн эч кандай чыгым жок. Эгер сиз мага окшоп оппссуз философияны жайылтсаңыз, анда бул өзгөчө чакан командалар үчүн абдан ыңгайлуу болот.
ыкмалар
Helm - бул кызматты башкаруунун жалгыз чечими эмес. Бул боюнча көптөгөн суроолор бар, балким, үчүнчү версия ушунчалык тез пайда болгон. Албетте, альтернативалар бар.
Бул адистештирилген чечимдер болушу мүмкүн, мисалы, Ksonnet же Metaparticle. Сиз классикалык инфраструктураны башкаруу куралдарыңызды (Ansible, Terraform, Chef ж.б.) мен айткан максаттар үчүн колдоно аласыз.
Акыры бир чечим бар , анын популярдуулугу өсүп жатат.
Operator Framework - бул Helm үчүн эң мыкты альтернатива.
Бул CNCF жана Kubernetes үчүн көбүрөөк жергиликтүү, бирок кирүүдөгү тоскоолдук алда канча жогору, көбүрөөк программалап, манифесттерди азыраак сүрөттөшүңүз керек.
Долбоор, Scaffold сыяктуу ар кандай кошумчалар бар. Алар жашоону бир топ жеңилдетет, мисалы, иштеп чыгуучуларга тесттик чөйрөнү жайылтуу үчүн Helm жөнөтүү жана ишке киргизүү циклин жөнөкөйлөштүрүшөт. Мен аларды күчтөндүрүүчүлөр деп атайт элем.
Бул жерде бардыгынын визуалдык диаграммасы.
X огунда болуп жаткан окуяларга сиздин жеке көзөмөлүңүздүн деңгээли, y огунда - Кубернетестин жергиликтүү деңгээли. Helm версия 2 ортодо бир жерге түшөт. 3-версияда абдан чоң эмес, бирок башкаруу жана жергиликтүү деңгээлдеги деңгээл жакшыртылды. Ksonnet деңгээлиндеги чечимдер дагы деле Helm 2ден төмөн. Бирок, бул дүйнөдө дагы эмне бар экенин билүү үчүн аларды карап чыгуу керек. Албетте, конфигурация менеджериңиз сиздин көзөмөлүңүздө болот, бирок ал Кубернетеске таптакыр таандык эмес.
Оператор алкактары толугу менен Кубернетеске таандык жана аны алда канча жарашыктуу жана кылдат башкарууга мүмкүндүк берет (бирок кирүү деңгээли жөнүндө унутпаңыз). Тескерисинче, бул Helm аркылуу көп сандагы тиркемелерди таңгактоочу массалык комбайнга караганда, адистештирилген колдонууга жана аны башкарууну түзүүгө ылайыктуу.
Extenders жөн гана башкарууну бир аз жакшыртат, иштин жүрүшүн толуктайт же CI/CD түтүктөрүндөгү бурчтарды кесип.
Helm келечеги
Жакшы жаңылык Helm 3 келе жатат. Helm 3.0.0-alpha.2 альфа версиясы мурунтан эле чыгарылган, сиз аны сынап көрүңүз. Бул кыйла туруктуу, бирок функционалдуулугу дагы эле чектелген.
Эмне үчүн сизге Helm 3 керек? Биринчиден, бул окуя жөнүндө Тиллердин жок болушу, компоненти катары. Бул, сиз түшүнгөндөй, алдыга жасалган чоң кадам, анткени архитектуранын коопсуздугу жагынан баары жөнөкөйлөштүрүлгөн.
Helm 2 түзүлгөндө, ал Kubernetes 1.8 же андан да мурун болгон, көптөгөн түшүнүктөр жетиле элек болчу. Мисалы, CRD концепциясы азыр жигердүү ишке ашырылып жатат жана Хелм ишке ашырат CRD колдонуңузструктураларды сактоо үчүн. Бул кардарды гана колдонууга жана сервер бөлүгүн сактоого болбойт. Демек, структуралар жана ресурстар менен иштөө үчүн түпкү Kubernetes буйруктарын колдонуңуз. Бул алга карай жасалган зор кадам.
Пайда болот жергиликтүү OCI репозиторийлерин колдоо (Ачык контейнер демилгеси). Бул чоң демилге жана Хелм биринчи кезекте өз диаграммаларын жайгаштырууга кызыкдар. Мисалы, Docker Hub көптөгөн OCI стандарттарын колдойт. Мен ойлобойм, бирок, балким, классикалык Docker репозиторий провайдерлери сизге Helm диаграммаларыңызды жайгаштыруу мүмкүнчүлүгүн бере башташат.
Мен үчүн талаштуу окуя Lua колдоо, скрипттерди жазуу үчүн шаблондук кыймылдаткыч катары. Мен Луанын чоң күйөрманы эмесмин, бирок бул толугу менен кошумча функция болмок. Мен муну 3 жолу текшердим - Луаны колдонуунун кереги жок. Ошондуктан, Луаны колдонгусу келгендер, Go жактыргандар биздин чоң лагерге кошулуп, бул үчүн go-tmpl колдонушат.
Акыр-аягы, мен сөзсүз жетишпей жаткан нерсе болду схеманын пайда болушу жана маалымат түрүн текшерүү. Мындан ары int же сапта көйгөйлөр болбойт, нөлдү кош тырмакчага коюунун кереги жок. JSONS схемасы пайда болот, ал сиз муну баалуулуктар үчүн ачык сүрөттөөгө мүмкүндүк берет.
Катуу кайра иштетилет окуяга негизделген модель. Ал буга чейин концептуалдык түрдө сүрөттөлгөн. Helm 3 бутагын караңыз, ошондо сиз канча окуялар, илгичтер жана башка нерселер кошулганын көрөсүз, бул абдан жөнөкөйлөштүрөт жана экинчи жагынан, жайгаштыруу процесстерин жана аларга болгон реакцияларды көзөмөлдөөнү кошот.
Helm 3 бизге Helm 2 жакпагандыктан эмес, Кубернетес өнүккөндүктөн жөнөкөй, коопсуз жана кызыктуураак болот. Демек, Хелм Kubernetes иштеп чыгууларын колдоно алат жана ал боюнча Kubernetes үчүн мыкты менеджерлерди түзө алат.
Дагы бир жакшы кабар - бул Александр Хайёров сага мындай дейт: Эске сала кетсек, Москвада иштеп чыгуу, сыноо жана эксплуатациялоо процесстерин интеграциялоо боюнча конференция өтөт 30-сентябрда жана 1-октябрда. Сиз дагы 20-августка чейин кыла аласыз жана чечүү менен тажрыйбаңыз жөнүндө айтып бериңиз DevOps мамилесинин милдеттери.
Конференция өткөрүү пункттарын жана жаңылыктарды төмөнкү даректен ээрчиңиз и .
Source: www.habr.com