Суштината на приказната за најпопуларниот менаџер на пакети за Kubernetes може да се прикаже со помош на емотикони:
- кутијата е Helm (што е најблиску до најновото издание на Emoji);
- брава - безбедност;
- малиот човек е решението на проблемот.
Всушност, сè ќе биде малку покомплицирано, а приказната е полна со технички детали за тоа Како да се направи кормилото безбедно.
- Накратко што е Helm доколку не сте знаеле или сте заборавиле. Кои проблеми ги решава и каде се наоѓа во екосистемот.
- Ајде да ја погледнеме архитектурата на Helm. Ниту еден разговор за безбедноста и како да се направи алатка или решение побезбедно не е завршен без разбирање на архитектурата на компонентата.
- Ајде да разговараме за компонентите на кормилото.
- Најгорливото прашање е иднината - новата верзија на Helm 3.
Сè во оваа статија се однесува на Helm 2. Оваа верзија е моментално во производство и најверојатно е онаа што ја користите во моментот, а таа е верзијата што ги содржи безбедносните ризици.
За говорникот: Александар Кајоров () се развива веќе 10 години, помагајќи да се подобри содржината и се приклучи на комисијата . Сега тој работи во Chainstack како водечки развој - ова е хибрид помеѓу менаџер за развој и лице кое е одговорно за доставување конечни изданија. Односно, се наоѓа на бојното поле, каде што сè се случува од создавањето на производот до неговото функционирање.
Chainstack е мал, активно растечки стартап чија мисија е да им овозможи на клиентите да заборават на инфраструктурата и комплексноста на работењето со децентрализирани апликации; тимот за развој се наоѓа во Сингапур. Не барајте од Chainstack да продава или купи криптовалута, туку понудете му да зборувате за рамки на блокчејн на претпријатија, и тие со задоволство ќе ви одговорат.
кормилото
Ова е менаџер на пакети (табела) за Kubernetes. Најинтуитивен и универзален начин да се донесат апликациите во кластерот Kubernetes.
Ние, се разбира, зборуваме за поструктурен и индустриски пристап отколку создавање ваши манифестации на YAML и пишување мали комунални услуги.
Штилата е најдоброто што е моментално достапно и популарно.
Зошто Хем? Првенствено затоа што е поддржан од CNCF. Cloud Native е голема организација и е матична компанија за проекти Kubernetes, etcd, Fluentd и други.
Друг важен факт е дека Helm е многу популарен проект. Кога почнав да зборувам за тоа како да го направам Helm безбеден во јануари 2019 година, проектот имаше илјада ѕвезди на GitHub. До мај имаше 12 илјади од нив.
Многу луѓе се заинтересирани за Helm, па дури и ако сè уште не го користите, ќе имате корист ако знаете за неговата безбедност. Безбедноста е важна.
Основниот тим на Helm е поддржан од Microsoft Azure и затоа е прилично стабилен проект, за разлика од многу други. Објавувањето на Helm 3 Alpha 2 во средината на јули покажува дека има доста луѓе кои работат на проектот и тие имаат желба и енергија да го развијат и подобрат Helm.
Helm решава неколку основни проблеми за управување со апликации во Kubernetes.
- Пакување апликација. Дури и апликацијата како „Здраво, свет“ на WordPress веќе се состои од неколку услуги и сакате да ги спакувате заедно.
- Управување со сложеноста што доаѓа со управувањето со овие апликации.
- Животен циклус што не завршува по инсталирањето или распоредувањето на апликацијата. Продолжува да живее, треба да се ажурира, а Хелм помага во тоа и се обидува да ги донесе вистинските мерки и политики за ова.
Вреќање тој е организиран на јасен начин: има метаподатоци во целосна согласност со работата на редовен менаџер на пакети за Linux, Windows или MacOS. Односно складиште, зависности од различни пакети, мета информации за апликации, поставки, карактеристики за конфигурација, индексирање на информации итн. Helm ви овозможува да го добиете и користите сето ова за апликации.
Управување со сложеност. Ако имате многу апликации од ист тип, тогаш е потребна параметаризација. Шаблоните доаѓаат од ова, но за да избегнете да смислите свој начин на креирање шаблони, можете да го користите она што Helm го нуди надвор од кутијата.
Управување со животниот циклус на апликацијата - Според мене, ова е најинтересното и најнерешено прашање. Ова е причината зошто дојдов во Хелм во минатото. Требаше да го следиме животниот циклус на апликацијата и сакавме да ги преместиме нашите CI/CD и циклусите на апликацијата на оваа парадигма.
Штилата ви овозможува:
- управување со распоредувањата, го воведува концептот на конфигурација и ревизија;
- успешно извршување на враќање назад;
- користете куки за различни настани;
- додадете дополнителни проверки на апликациите и одговорете на нивните резултати.
Покрај тоа Штилата има „батерии“ - огромен број вкусни работи кои можат да се вклучат во форма на приклучоци, поедноставувајќи го вашиот живот. Приклучоците можат да се напишат независно, тие се прилично изолирани и не бараат хармонична архитектура. Ако сакате да имплементирате нешто, препорачувам да го направите како приклучок, а потоа евентуално да го вклучите во upstream.
Helm се заснова на три главни концепти:
- Репо на графикон — опис и низа параметризации можни за вашиот манифест.
- config — односно вредностите што ќе се применат (текст, нумерички вредности итн.).
- Ослободување ги собира двете горни компоненти и заедно се претвораат во Release. Изданијата може да се верзираат, а со тоа да се постигне организиран животен циклус: мали за време на инсталацијата и големи во моментот на надградба, намалување или враќање назад.
Архитектура на кормилото
Дијаграмот концептуално ја прикажува архитектурата на високо ниво на Хелм.
Да ве потсетам дека Хелм е нешто поврзано со Кубернетес. Затоа, не можеме без кластерот Kubernetes (правоаголник). Компонентата kube-apiserver се наоѓа на главниот. Без Helm имаме Kubeconfig. Helm носи една мала бинарна, ако може така да се нарече, алатката Helm CLI, која е инсталирана на компјутер, лаптоп, мејнфрејм - на било што.
Но, ова не е доволно. Helm има серверска компонента наречена Tiller. Ги претставува интересите на Хелм во кластерот; тоа е апликација во кластерот Кубернетес, исто како и секоја друга.
Следната компонента на Chart Repo е складиште со графикони. Постои официјално складиште, а може да има и приватно складиште на компанија или проект.
Интеракција
Ајде да погледнеме како компонентите на архитектурата комуницираат кога сакаме да инсталираме апликација користејќи Helm.
- Зборуваме
Helm install, пристапете до складиштето (Chart Repo) и добијте дијаграм на Helm.
- Услужната алатка Helm (Helm CLI) комуницира со Kubeconfig со цел да открие со кој кластер да контактира.
- Откако ја добивме оваа информација, алатката се однесува на Tiller, кој се наоѓа во нашиот кластер, како апликација.
- Тилер го повикува Kube-apiserver да изврши дејства во Kubernetes, да создаде некои објекти (услуги, подлоги, реплики, тајни итн.).
Следно, ќе го комплицираме дијаграмот за да го видиме векторот на напад на кој може да биде изложена целата архитектура на Helm како целина. И тогаш ќе се обидеме да ја заштитиме.
Вектор на напад
Првата потенцијална слаба точка е привилегиран API-корисникот. Како дел од шемата, ова е хакер кој доби административен пристап до Helm CLI.
Непривилегиран корисник на API може да претставува и опасност ако е некаде во близина. Таквиот корисник ќе има различен контекст, на пример, тој може да се поправи во еден кластер именски простор во поставките Kubeconfig.
Најинтересниот вектор за напад може да биде процес кој се наоѓа во кластер некаде во близина на Тилер и може да му пристапи. Ова може да биде веб-сервер или микросервис што ја гледа мрежната средина на кластерот.
Егзотична, но сè попопуларна варијанта на напад вклучува Chart Repo. Табелата создадена од бескрупулозен автор може да содржи небезбедни ресурси, а вие ќе ја комплетирате ако ја земете на вера. Или може да ја замени табелата што ја преземате од официјалното складиште и, на пример, да создаде ресурс во форма на политики и да го зголеми неговиот пристап.
Ајде да се обидеме да ги одбраниме нападите од сите овие четири страни и да откриеме каде има проблеми во архитектурата на кормилото, а каде, можеби, нема.
Ајде да го зголемиме дијаграмот, да додадеме повеќе елементи, но да ги задржиме сите основни компоненти.
Helm CLI комуницира со Chart Repo, комуницира со Kubeconfig, а работата се пренесува во кластерот во компонентата Tiller.
Тилер е претставен со два објекти:
- Tiller-deploy svc, што изложува одредена услуга;
- Tiller-deploy pod (на дијаграмот во една копија во една реплика), на кој работи целото оптоварување, кое пристапува до кластерот.
За интеракција се користат различни протоколи и шеми. Од безбедносна гледна точка, најмногу нè интересира:
- Механизмот со кој Helm CLI пристапува до репото на графиконот: каков протокол, дали има автентикација и што може да се направи со него.
- Протоколот со кој Helm CLI, користејќи kubectl, комуницира со Тилер. Ова е RPC сервер инсталиран во кластерот.
- Самиот Tiller е достапен за микросервиси кои живеат во кластерот и комуницира со Kube-apiserver.
Ајде да разговараме за сите овие области по ред.
RBAC
Нема смисла да се зборува за каква било безбедност за Helm или која било друга услуга во кластерот, освен ако не е овозможено RBAC.
Се чини дека ова не е најновата препорака, но сигурен сум дека многу луѓе сè уште немаат овозможено RBAC дури ни во производството, бидејќи е многу гужва и многу работи треба да се конфигурираат. Сепак, ве охрабрувам да го направите ова.
— веб-страница адвокат за RBAC. Содржи огромна количина на интересни материјали кои ќе ви помогнат да го поставите RBAC, да покажете зошто е добар и како во основа да живеете со него во производството.
Ќе се обидам да објаснам како функционираат Тилер и RBAC. Tiller работи внатре во кластерот под одредена услуга за сметка. Вообичаено, ако RBAC не е конфигуриран, ова ќе биде суперкорисникот. Во основната конфигурација, Тилер ќе биде администратор. Ова е причината зошто често се вели дека Tiller е SSH тунел до вашиот кластер. Всушност, ова е точно, така што можете да користите посебна сметка за посветена услуга наместо стандардната сметка за услуга на дијаграмот погоре.
Кога ќе го иницијализирате Helm и ќе го инсталирате на серверот за прв пат, можете да ја поставите сметката на услугата користејќи --service-account. Ова ќе ви овозможи да користите корисник со минимален потребен сет на права. Точно, ќе треба да создадете таква „венец“: Role и RoleBinding.
За жал, Хелм нема да го направи ова за вас. Вие или вашиот администратор на кластерот Kubernetes треба однапред да подготвите збир на улоги и RoleBindings за сметката на услугата за да го поминете Helm.
Се поставува прашањето - која е разликата помеѓу Role и ClusterRole? Разликата е во тоа што ClusterRole работи за сите именски простори, за разлика од обичните Roles и RoleBindings, кои работат само за специјализиран именски простор. Можете да конфигурирате политики за целиот кластер и сите именски простори или персонализирани за секој именски простор поединечно.
Вреди да се спомене дека RBAC решава уште еден голем проблем. Многу луѓе се жалат дека Хелм, за жал, не е мултинастанатност (не поддржува мултинастанување). Ако неколку тимови консумираат кластер и користат Helm, во основа е невозможно да се постават политики и да се ограничи нивниот пристап во рамките на овој кластер, бидејќи постои одредена сметка на услуга под која работи Helm и ги создава сите ресурси во кластерот од под него. , што понекогаш е многу незгодно. Ова е точно - како самата бинарна датотека, како и процесот, Хелм Тилер нема концепт за мултизакуп.
Сепак, постои одличен начин кој ви овозможува да го стартувате Tiller повеќе пати во кластер. Нема проблем со ова, Tiller може да се лансира во секој именски простор. Така, можете да ги користите RBAC, Kubeconfig како контекст и да го ограничите пристапот до специјална Helm.
Ќе изгледа вака.
На пример, постојат две Kubeconfig со контекст за различни тимови (два простори за имиња): X Team за развојниот тим и администраторскиот кластер. Администраторскиот кластер има сопствен широк Tiller, кој се наоѓа во именскиот простор на системот Kube, соодветно напредна услуга-сметка. И посебен именски простор за развојниот тим, тие ќе можат да ги распоредат своите услуги во посебен именски простор.
Ова е остварлив пристап, Тилер не е толку гладен за моќ што во голема мера ќе влијае на вашиот буџет. Ова е едно од брзите решенија.
Слободно конфигурирајте го Tiller одделно и обезбедете му на Kubeconfig контекст за тимот, за специфичен развивач или за околината: Dev, Staging, Production (сомнително е дека сè ќе биде на истиот кластер, сепак, ова може да се направи).
Продолжувајќи ја нашата приказна, да се префрлиме од RBAC и да разговараме за ConfigMaps.
ConfigMaps
Helm користи ConfigMaps како своја продавница за податоци. Кога зборувавме за архитектура, никаде немаше база на податоци што ќе складира информации за изданија, конфигурации, враќања итн. За ова се користи ConfigMaps.
Главниот проблем со ConfigMaps е познат - тие во принцип се небезбедни; невозможно е да се складираат чувствителни податоци. Зборуваме за сè што не треба да оди подалеку од услугата, на пример, лозинки. Најдобриот начин за Helm во моментов е да се префрли од користење ConfigMaps на тајни.
Ова е направено многу едноставно. Отфрлете ја поставката Tiller и наведете дека складирањето ќе биде тајни. Потоа за секое распоредување нема да добивате ConfigMap, туку тајна.
Може да тврдите дека самите тајни се чуден концепт и не многу сигурен. Сепак, вреди да се разбере дека самите развивачи на Кубернетес го прават тоа. Почнувајќи од верзијата 1.10, т.е. Веќе подолго време, беше можно, барем во јавни облаци, да се поврзе правилното складирање за складирање тајни. Тимот сега работи на начини за подобро дистрибуирање на пристапот до тајни, индивидуални подлоги или други ентитети.
Подобро е да се пренесе Storage Helm во тајни, а тие, пак, се обезбедени централно.
Секако дека ќе остане ограничување за складирање податоци од 1 MB. Helm овде користи etcd како дистрибуирано складирање за ConfigMaps. И таму сметаа дека ова е соодветен податочен дел за репликација итн. Има интересна дискусија за ова на Редит, препорачувам да го најдете ова смешно четиво за викенд или да го прочитате извадокот .
Табела репо
Табелите се социјално најранливите и можат да станат извор на „Човек во средината“, особено ако користите решение за акции. Пред сè, зборуваме за складишта кои се изложени преку HTTP.
Дефинитивно треба да го изложите Helm Repo преку HTTPS - ова е најдобрата опција и е евтина.
Обрнете внимание механизам за потпис на графиконот. Технологијата е едноставна како пекол. Ова е истото што го користите на GitHub, обична PGP машина со јавни и приватни клучеви. Поставете и уверете се, имајќи ги потребните клучеви и потпишувајќи сè, дека ова е навистина вашата табела.
Покрај тоа, Клиентот на Helm поддржува TLS (не во смисла на HTTP од страна на серверот, туку меѓусебен TLS). Можете да ги користите клучевите на серверот и клиентот за да комуницирате. Да бидам искрен, не користам таков механизам затоа што не сакам меѓусебни сертификати. Во основа, - главната алатка за поставување на Helm Repo за Helm 2 - поддржува и основна автетика. Можете да користите основна проверка ако е поудобно и потивко.
Постои и приклучок , што ви овозможува да хостирате Chart Repos на Google Cloud Storage. Ова е доста погодно, работи одлично и е сосема безбедно, бидејќи сите опишани механизми се рециклираат.
Ако овозможите HTTPS или TLS, користите mTLS и овозможите основна проверка за дополнително намалување на ризиците, ќе добиете безбеден канал за комуникација со Helm CLI и Chart Repo.
gRPC API
Следниот чекор е многу важен - да се обезбеди Tiller, кој се наоѓа во кластерот и е, од една страна, сервер, од друга страна, самиот пристапува до други компоненти и се обидува да се преправа дека е некој.
Како што веќе реков, Tiller е услуга што го изложува gRPC, клиентот Helm доаѓа до него преку gRPC. Стандардно, се разбира, TLS е оневозможен. Зошто е направено ова е дискутабилно прашање, ми се чини дека го поедноставив поставувањето на почетокот.
За производство, па дури и за поставување, препорачувам да се овозможи TLS на gRPC.
Според мое мислење, за разлика од mTLS за графикони, ова е соодветно овде и се прави многу едноставно - генерира PQI инфраструктура, креирај сертификат, стартувај Tiller, префрли го сертификатот за време на иницијализацијата. По ова, можете да ги извршите сите команди на Helm, прикажувајќи се со генерираниот сертификат и приватниот клуч.
На овој начин ќе се заштитите од сите барања до Тилер надвор од кластерот.
Значи, го обезбедивме каналот за поврзување со Tiller, веќе разговаравме за RBAC и ги приспособивме правата на аписерверот Kubernetes, намалувајќи го доменот со кој може да комуницира.
Заштитена кормила
Ајде да го погледнеме конечниот дијаграм. Тоа е истата архитектура со истите стрелки.
Сите врски сега можат безбедно да се нацртаат зелено:
- за Chart Repo користиме TLS или mTLS и основна проверка;
- mTLS за Tiller, и тој е изложен како услуга gRPC со TLS, користиме сертификати;
- кластерот користи специјална сметка за услуга со Role и RoleBinding.
Значително го обезбедивме кластерот, но некој паметен рече:
„Може да има само едно апсолутно безбедно решение - исклучен компјутер, кој се наоѓа во бетонска кутија и го чуваат војници“.
Постојат различни начини да се манипулира со податоците и да се најдат нови вектори за напад. Сепак, уверен сум дека овие препораки ќе постигнат основен индустриски стандард за безбедност.
бонус
Овој дел не е директно поврзан со безбедноста, но исто така ќе биде корисен. Ќе ви покажам неколку интересни работи за кои малкумина знаат. На пример, како да пребарувате графикони - официјални и неофицијални.
Во складиштето Сега има околу 300 графикони и два текови: стабилна и инкубатор. Секој кој придонесува, знае одлично колку е тешко да се стигне од инкубатор до штала и колку е лесно да се лета од штала. Сепак, ова не е најдобрата алатка за пребарување на графикони за Prometheus и што друго сакате, од една едноставна причина - тоа не е портал каде што можете удобно да пребарувате пакети.
Но, постои услуга , што го прави многу поудобно да се најдат графикони. Што е најважно, има многу повеќе надворешни складишта и речиси 800 шарм на располагање. Плус, можете да го поврзете вашето складиште ако поради некоја причина не сакате да ги испратите вашите графикони на стабилна.
Обидете се со hub.helm.sh и ајде да го развиеме заедно. Оваа услуга е во рамките на проектот Helm, па дури можете да придонесете за нејзиниот интерфејс ако сте развивач од предниот дел и само сакате да го подобрите изгледот.
Исто така, би сакал да го привлечам вашето внимание Отворете интеграција на API на брокер за услуги. Звучи незгодно и нејасно, но ги решава проблемите со кои се соочуваат сите. Дозволете ми да објаснам со едноставен пример.
Постои кластер Kubernetes во кој сакаме да извршиме класична апликација - WordPress. Општо земено, потребна е база на податоци за целосна функционалност. Постојат многу различни решенија, на пример, можете да стартувате сопствена државна услуга. Ова не е многу погодно, но многу луѓе го прават тоа.
Други, како нас во Chainstack, користат управувани бази на податоци како MySQL или PostgreSQL за нивните сервери. Затоа нашите бази на податоци се наоѓаат некаде во облакот.
Но, се појавува проблем: треба да ја поврземе нашата услуга со база на податоци, да создадеме вкус на базата на податоци, да ја пренесеме акредитацијата и некако да управуваме со неа. Сето ова обично се прави рачно од администраторот на системот или развивачот. И нема проблем кога има малку апликации. Кога ги има многу, потребен ви е комбајн. Има таков жетвар - тоа е сервисен брокер. Ви овозможува да користите специјален приклучок за јавен облак кластер и да нарачувате ресурси од давателот преку Брокер, како да е API. За да го направите ова, можете да ги користите домашните алатки на Kubernetes.
Многу е едноставно. Можете да побарате, на пример, Managed MySQL во Azure со основно ниво (ова може да се конфигурира). Со користење на Azure API, базата на податоци ќе биде креирана и подготвена за употреба. Не треба да се мешате со ова, приклучокот е одговорен за ова. На пример, OSBA (приклучок Azure) ќе ги врати акредитивите на услугата и ќе ги предаде на Helm. Ќе можете да користите WordPress со облак MySQL, воопшто да не се занимавате со управувани бази на податоци и да не се грижите за државните услуги внатре.
Можеме да кажеме дека Helm делува како лепак што, од една страна, ви овозможува да распоредите услуги, а од друга, да ги трошите ресурсите на давателите на облак.
Можете да напишете свој приклучок и да ја користите целата оваа приказна во просторија. Тогаш едноставно ќе имате свој приклучок за корпоративниот Cloud провајдер. Препорачувам да го испробате овој пристап, особено ако имате голем размер и сакате брзо да ги распоредите програмите, поставките или целата инфраструктура за одредена функција. Ова ќе го олесни животот за вашите операции или DevOps.
Друго откритие што веќе го споменав е helm-gcs приклучок, кој ви овозможува да користите кофи на Google (складирање на предмети) за складирање на графиконите на Helm.
Потребни ви се само четири команди за да започнете да го користите:
- инсталирај го приклучокот;
- иницирај го;
- поставете ја патеката до корпата, која се наоѓа во gcp;
- објавувајте графикони на стандарден начин.
Убавината е што за авторизација ќе се користи методот на мајчин gcp. Можете да користите сметка за услуга, сметка за програмер, што и да посакате. Многу е удобен и не чини ништо за работа. Ако вие, како мене, ја промовирате филозофијата без опс, тогаш ова ќе биде многу погодно, особено за малите тимови.
Алтернативи
Helm не е единственото решение за управување со услуги. Има многу прашања во врска со тоа, па веројатно затоа третата верзија се појави толку брзо. Секако дека има алтернативи.
Овие можат да бидат специјализирани решенија, на пример, Ksonnet или Metaparticle. Можете да ги користите вашите класични алатки за управување со инфраструктура (Ansible, Terraform, Chef, итн.) за истите цели за кои зборував.
Конечно има решение , чија популарност расте.
Рамката на операторот е најдобрата алтернатива на Helm што треба да се разгледа.
Тој е повеќе роден во CNCF и Kubernetes, но бариерата за влез е многу поголема, треба повеќе да програмирате, а помалку да опишувате манифестации.
Постојат различни додатоци, како што се Draft, Scaffold. Тие многу го олеснуваат животот, на пример, го поедноставуваат циклусот на испраќање и лансирање на Helm за програмерите да распоредат средина за тестирање. Би ги нарекол моќници.
Еве визуелна табела каде е сè.
На х-оската е нивото на вашата лична контрола врз она што се случува, на y-оската е нивото на мајчинството на Кубернет. Верзијата 2 на кормилото паѓа некаде на средина. Во верзијата 3, не енормно, но и контролата и нивото на мајчинство се подобрени. Решенијата на ниво на Ksonnet сè уште се инфериорни дури и во однос на Helm 2. Сепак, вреди да се погледнат за да се знае што друго има на овој свет. Се разбира, вашиот менаџер за конфигурација ќе биде под ваша контрола, но тој апсолутно не е мајчин за Кубернетес.
Рамката на операторот е апсолутно родена во Кубернетес и ви овозможува да управувате со неа многу поелегантно и поскрупулозно (но запомнете за влезното ниво). Наместо тоа, ова е погодно за специјализирана апликација и создавање на менаџмент за тоа, наместо за масовен жетвар за пакување на огромен број апликации користејќи Helm.
Проширувачите едноставно малку ја подобруваат контролата, го надополнуваат работниот тек или ги намалуваат аглите на цевководите CI/CD.
Иднината на Хелм
Добрата вест е дека доаѓа Helm 3. Алфа верзијата на Helm 3.0.0-alpha.2 е веќе објавена, можете да ја пробате. Тој е доста стабилен, но функционалноста е сè уште ограничена.
Зошто ви е потребен Helm 3? Како прво, ова е приказна за исчезнувањето на Тилер, како компонента. Ова, како што веќе разбирате, е огромен чекор напред, бидејќи од гледна точка на безбедноста на архитектурата, сè е поедноставено.
Кога беше создаден Helm 2, што беше околу времето на Kubernetes 1.8 или уште порано, многу од концептите беа незрели. На пример, концептот CRD сега активно се имплементира, а Хелм ќе го направи тоа користете CRDза складирање на структури. Ќе може да се користи само клиентот и да не се одржува делот на серверот. Според тоа, користете матични команди на Кубернет за да работите со структури и ресурси. Ова е огромен чекор напред.
Ќе се појави поддршка за матичните складишта на OCI (Иницијатива за отворен контејнер). Ова е огромна иницијатива, а Хелм е заинтересиран првенствено за да ги објави своите топ листи. Доаѓа до точка дека, на пример, Docker Hub поддржува многу OCI стандарди. Не погодувам, но можеби класичните даватели на складиштето Docker ќе почнат да ви даваат можност да ги хостирате вашите табели на Helm.
Контроверзната приказна за мене е Луа поддршка, како шаблон мотор за пишување скрипти. Не сум голем обожавател на Луа, но ова би било целосно опционална карактеристика. Го проверив ова 3 пати - користењето на Луа нема да биде потребно. Затоа, оние кои сакаат да можат да го користат Луа, оние кои сакаат Go, се придружуваат на нашиот огромен камп и користат go-tmpl за ова.
Конечно, она што дефинитивно ми недостасуваше беше појава на шема и валидација на типот на податоци. Нема да има повеќе проблеми со int или стринг, нема потреба да се завиткува нула во двојни наводници. Ќе се појави шема JSONS која ќе ви овозможи експлицитно да го опишете ова за вредностите.
Ќе биде силно преработен модел управуван од настани. Веќе е концептуално опишано. Погледнете ја гранката Helm 3 и ќе видите колку настани, куки и други работи се додадени, што во голема мера ќе го поедностави, а од друга страна, ќе додаде контрола врз процесите на распоредување и реакциите на нив.
Helm 3 ќе биде поедноставен, побезбеден и позабавен, не затоа што не ни се допаѓа Helm 2, туку затоа што Kubernetes станува понапреден. Соодветно на тоа, Хелм може да го искористи развојот на Кубернетс и да создаде одлични менаџери за Кубернетис на него.
Друга добра вест е тоа Александар Кајоров ќе ви каже, Да потсетиме дека конференцијата за интеграција на процесите за развој, тестирање и работење ќе се одржи во Москва 30 септември и 1 октомври. Сè уште можете да го направите тоа до 20 август и кажете ни за вашето искуство со решението задачи на пристапот DevOps.
Следете ги контролните пунктови и новостите на конференцијата на и .
Извор: www.habr.com