Предпазни каски

Същността на историята за най-популярния мениджър на пакети за Kubernetes може да бъде изобразена с помощта на емотикони:

• кутията е Helm (това е най-подходящото нещо в последната версия на Emoji);
• брава - сигурност;
• човекът е решението на проблема.

Всъщност всичко ще бъде малко по-сложно и историята е пълна с технически подробности за това как как да направите Helm защитен.

• Накратко какво е Helm, ако не сте знаели или сте забравили. Какви проблеми решава и къде се намира в екосистемата.
• Помислете за архитектурата на Helm. Нито един разговор за сигурността и как да направите инструмент или решение по-сигурен не е завършен без разбиране на архитектурата на компонента.
• Нека обсъдим компонентите на Helm.
• Най-горещият въпрос е бъдещето - новата версия на Helm 3. 

Всичко в тази статия се отнася за Helm 2. Тази версия в момента е в производство и най-вероятно е тази, която използвате в момента, и е тази с рискове за сигурността.

Относно говорителя: Александър Хайоров (allexx) се развива в продължение на 10 години, като помага за подобряване на съдържанието Москва Python Conf++ и се присъедини към комисията Хелм връх. Сега той работи в Chainstack като ръководител на разработката - това е хибрид между мениджър по разработката и човек, който отговаря за доставката на финалните версии. Тоест, той се намира на мястото на военните действия, където се случва всичко от създаването на продукт до неговата експлоатация.

Chainstack е малък, активно развиващ се стартъп, чиято мисия е да позволи на клиентите да забравят за инфраструктурата и сложността на оперирането с децентрализирани приложения, екипът за разработка се намира в Сингапур. Не искайте от Chainstack да продава или купува криптовалута, но предлагайте да поговорим за корпоративни блокчейн рамки и те с радост ще ви отговорят.

Шлем

Това е мениджър на пакети (диаграма) за Kubernetes. Най-ясният и най-гъвкав начин за пренасяне на приложения към клъстер на Kubernetes.

Тук, разбира се, става въпрос за по-структурен и индустриален подход от създаването на ваши собствени YAML манифести и писането на малки помощни програми.

Helm е най-доброто, което сега е налично и популярно.

Защо Helm? Основно защото се поддържа от CNCF. Cloud Native е голяма организация и е компанията майка за Kubernetes, etcd, Fluentd и други.

Друг важен факт е, че Helm е много популярен проект. Когато през януари 2019 г. за първи път си помислих да говоря за това как да направя Helm защитен, проектът имаше хиляда звезди в GitHub. До май те бяха 12 XNUMX.

Много хора се интересуват от Helm, така че дори и да не го използвате все още, знанието за неговата сигурност ще ви бъде полезно. Безопасността е важна.

Основният екип на Helm е подкрепен от Microsoft Azure и като такъв е доста стабилен проект, за разлика от много други. Пускането на Helm 3 Alpha 2 в средата на юли показва, че доста хора работят по проекта и имат желанието и силата да развиват и подобряват Helm.

Helm адресира няколко проблема с управлението на основните приложения в Kubernetes.

• Опаковка на приложението. Дори приложение като „Hello, World“ на WordPress вече се състои от няколко услуги и те искат да бъдат пакетирани заедно.
• Управление на сложността, която идва с управлението на тези приложения.
• Жизнен цикъл, който не завършва след инсталиране или внедряване на приложението. Продължава да живее, трябва да се актуализира и Helm помага в това и се опитва да въведе правилните мерки и политики за това.

Опаковане подредени по разбираем начин: има метаданни в пълно съответствие с работата на конвенционален мениджър на пакети за Linux, Windows или MacOS. Тоест, хранилището, зависимостите от различни пакети, метаинформация за приложения, настройки, функции за конфигурация, информация за индексиране и т.н. Всичко това Helm ви позволява да получавате и използвате за приложения.

Управление на сложността. Ако имате много приложения от един и същи тип, тогава е необходима параметризация. От това следват шаблони, но за да не измисляте свой собствен начин за създаване на шаблони, можете да използвате това, което Helm предлага извън кутията.

Управление на жизнения цикъл на приложението - според мен това е най-интересният и неразрешен въпрос. Ето защо по едно време дойдох в Хелм. Трябваше да следим жизнения цикъл на приложението, искахме да преместим нашите цикли на CI/CD и приложения в тази парадигма.

Helm ви позволява да:

• управлява внедрявания, въвежда концепцията за конфигурация и ревизия;
• успешно извършване на връщане назад;
• използвайте куки за различни събития;
• добавете допълнителни проверки на приложението и отговорете на техните резултати.

Освен това Шлемът има "батерии" - огромен брой вкусни неща, които могат да бъдат включени под формата на добавки, опростяващи живота ви. Добавките могат да бъдат написани независимо, те са доста изолирани и не изискват последователна архитектура. Ако искате да внедрите нещо, препоръчвам да го направите като плъгин и след това евентуално да го включите в upstream.

Helm се основава на три основни концепции:

• Графика Repos — описание и набор от възможни параметри за вашия манифест. 
• Config —тоест стойностите, които трябва да се приложат (текст, числови стойности и т.н.).
• Освободете събира двата горни компонента и заедно те се превръщат в Release. Изданията могат да бъдат с версии, като по този начин се постига организация на жизнения цикъл: малък по време на инсталиране и голям по време на надграждане, понижаване или връщане назад.

Архитектура на кормилото

Диаграмата концептуално изобразява архитектурата на високо ниво на 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 потребител също може да представлява опасност, ако е някъде наблизо. Такъв потребител ще има различен контекст, например може да бъде фиксиран в едно пространство на имена на клъстер в настройките на Kubeconfig.

Най-интересният вектор на атака може да бъде процес, който е вътре в клъстера някъде близо до Tiller и има достъп до него. Това може да бъде уеб сървър или микроуслуга, която вижда мрежовата среда на клъстера.

Екзотичен, но все по-популярен вариант на атаката е свързан с Chart Repo. Диаграма, създадена от безскрупулен автор, може да съдържа опасен ресурс и вие ще я следвате на вяра. Или той може да замени диаграмата, която изтегляте от официалното хранилище, и например да създаде ресурс под формата на политики и да ескалира достъпа до себе си.

Нека се опитаме да се преборим с атаките от всички тези четири страни и да разберем къде има проблеми в архитектурата на Helm и къде може би не.

Нека да увеличим схемата, да добавим още елементи, но да запазим всички основни компоненти.

Helm CLI комуникира с Chart Repo, взаимодейства с Kubeconfig, работата се прехвърля към клъстера към компонента Tiller.

Tiller е представен от два обекта:

• Tiller-deploy svc, който разкрива определена услуга;
• Tiller-deploy pod (на диаграмата в единичен екземпляр в една реплика), върху който работи цялото натоварване, което осъществява достъп до клъстера.

За взаимодействие се използват различни протоколи и схеми. От гледна точка на сигурността най-много се интересуваме от:

• Механизмът, чрез който Helm CLI осъществява достъп до репото на графиката: какъв е протоколът, има ли удостоверяване и какво може да се направи по въпроса.
• Протоколът, чрез който Helm CLI, използвайки kubectl, комуникира с Tiller. Това е RPC сървър, инсталиран вътре в клъстера.
• Самият Tiller е достъпен за микроуслуги, които са в клъстера и взаимодействат с Kube-apiserver.

Нека обсъдим всяка от тези области на свой ред.

RBAC

Безполезно е да говорим за каквато и да е сигурност за Helm или която и да е друга услуга в рамките на клъстера, освен ако RBAC не е активиран.

Изглежда, че това не е най-новата препоръка, но съм сигурен, че мнозина все още не са активирали RBAC дори в производството, защото е много суетене и има много за конфигуриране. Въпреки това ви призовавам да го направите.

https://rbac.dev/ — сайт-юрист за RBAC. Има огромно количество интересни материали, събрани там, които ще ви помогнат да настроите RBAC, да покажете защо е добър и как да живеете с него по принцип в производството.

Ще се опитам да обясня как работят Tiller и RBAC. Tiller работи вътре в клъстера под определен акаунт за услуга. Обикновено, ако RBAC не е конфигуриран, това ще бъде суперпотребителят. В основната конфигурация Tiller ще бъде администратор. Ето защо често се казва, че Tiller е SSH тунел към вашия клъстер. Всъщност това е така, така че можете да използвате отделен акаунт за специализирана услуга вместо акаунта за услуга по подразбиране в диаграмата по-горе.

Когато инициализирате Helm за първи път, когато го инсталирате на сървър, можете да настроите акаунт за услуга с --service-account. Това ще ви позволи да използвате потребител с минимално необходимия набор от права. Вярно е, че ще трябва да създадете такъв "гирлянд": Role и RoleBinding.

За съжаление Helm няма да направи това вместо вас. Вие или вашият администратор на клъстер Kubernetes трябва предварително да подготвите набор от роли, RoleBinding за акаунта на услугата, за да преминете през кормилото.

Възниква въпросът - каква е разликата между Role и ClusterRole? Разликата е, че ClusterRole работи за всички пространства от имена, за разлика от обикновените Role и RoleBinding, които работят само за специализирани пространства от имена. Можете да настроите политики за целия клъстер и всички пространства от имена, както и персонализирани за всяко пространство от имена поотделно.

Заслужава да се спомене, че RBAC решава друг голям проблем. Мнозина се оплакват, че Helm, за съжаление, не е multitenancy (не поддържа multitenancy). Ако няколко екипа консумират клъстер и използват Helm, по принцип е невъзможно да се настроят политики и да се диференцира достъпът им в рамките на този клъстер, тъй като има определен акаунт за услуга, от който работи Helm, и той създава всички ресурси в клъстера от под това, което понякога е много неудобно. Това е вярно - като самия двоичен файл, като процес, Хелм Тилър няма представа за мултинаемство.

Има обаче страхотен начин, който ви позволява да стартирате Tiller няколко пъти в клъстер. Няма проблем с това, Tiller може да се изпълнява във всяко пространство на имена. По този начин можете да използвате RBAC, Kubeconfig като контекст и да ограничите достъпа до специален Helm.

Ще изглежда така.

Например, има две Kubeconfigs с контекст за различни екипи (две пространства от имена): X Team за екипа за разработка и административен клъстер. Административният клъстер има свой собствен широк Tiller, който се намира в пространството на имената на системата Kube, съответно разширен акаунт за услуга. И отделно пространство от имена за екипа за разработка, те ще могат да разгръщат услугите си в специално пространство от имена.

Това е работещ подход, Tiller не е толкова лаком, че да засегне значително бюджета ви. Това е едно от бързите решения.

Чувствайте се свободни да конфигурирате Tiller отделно и да предоставите на Kubeconfig контекст за екип, за конкретен разработчик или за средата: Dev, Staging, Production (съмнително е всичко да бъде на един и същи клъстер, но може да се направи) .

Продължавайки нашата история, нека преминем от RBAC и да поговорим за ConfigMaps.

ConfigMaps

Helm използва ConfigMaps като хранилище на данни. Когато говорихме за архитектура, никъде нямаше база данни, която да съхранява информация за версии, конфигурации, връщания назад и т.н. За това се използва ConfigMaps.

Основният проблем с ConfigMaps е известен - те не са безопасни по принцип, те не може да съхранява чувствителни данни. Говорим за всичко, което не трябва да надхвърля услугата, например пароли. Най-родният начин за Helm в момента е да премине от използване на ConfigMaps към тайни.

Това се прави много просто. Заменете настройката на Tiller и укажете, че съхранението ще бъде тайно. След това за всяко внедряване ще получите не ConfigMap, а тайна.

Може да възразите, че самите тайни са странна концепция и не са много сигурни. Трябва обаче да се разбере, че самите разработчици на Kubernetes правят това. Започвайки от версия 1.10, т.е. за дълго време е възможно, поне в обществени облаци, да се свърже правилното хранилище за съхраняване на тайни. Сега екипът работи върху това как да разпредели още по-добре достъпа до тайни, отделни подове или други обекти.

По-добре е да преведете Storage Helm в тайни и на свой ред да ги защитите централно.

Разбира се, че ще остане Ограничение за съхранение на данни от 1 MB. Helm тук използва etcd като разпределено хранилище за ConfigMaps. И там са преценили, че това е подходящо парче данни за репликации и т.н. Има интересна дискусия в Reddit за това, препоръчвам да намерите това забавно четиво за уикенда или да прочетете стискането тук.

Графика Repos

Графиките са най-социално уязвимите и могат да станат източник на "Човек по средата", особено ако използвате стандартно решение. На първо място, говорим за хранилища, които са изложени чрез HTTP.

Определено трябва да изложите Helm Repo през HTTPS - това е най-добрият вариант и е евтин.

Обърнете внимание на механизъм за подпис на диаграма. Технологията е лесна за опозоряване. Това е същото като това, което използвате в GitHub, нормална PGP машина с публични и частни ключове. Настройте и бъдете сигурни, като имате правилните ключове и подписвате всичко, че това наистина е вашата диаграма.

Освен това, Клиентът на Helm поддържа TLS (не в смисъл на HTTP от страна на сървъра, а взаимен TLS). Можете да използвате сървърни и клиентски ключове за комуникация. Честно казано, не използвам такъв механизъм поради неприязънта си към взаимните сертификати. по принцип, chartmuseum - основният инструмент за настройка на Helm Repo за Helm 2 - също поддържа основно удостоверяване. Можете да използвате основно удостоверяване, ако е по-удобно и по-тихо.

Има и плъгин helm-gcs, което ви позволява да хоствате 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 извън клъстера.

И така, ние осигурихме канала за връзка с Tiller, вече обсъдихме RBAC и коригирахме правата на apiserver на Kubernetes, намалихме домейна, с който може да взаимодейства.

Защитен шлем

Нека да разгледаме крайната диаграма. Това е същата архитектура със същите стрелки.

Всички връзки вече могат безопасно да бъдат начертани в зелено:

• за Chart Repo използваме TLS или mTLS и основно удостоверяване;
• mTLS за Tiller и е изложен като gRPC услуга с TLS, ние използваме сертификати;
• клъстерът използва специален акаунт за услуга с Role и RoleBinding. 

Забележимо защитихме клъстера, но някой умен каза:

„Може да има само едно абсолютно безопасно решение - изключен компютър, който се намира в бетонна кутия и се охранява от войници.

Има различни начини за манипулиране на данни и намиране на нови вектори на атака. Убеден съм обаче, че тези препоръки ще ви позволят да приложите основния индустриален стандарт за сигурност.

премия

Тази част не е пряко свързана със сигурността, но също ще бъде полезна. Ще ви покажа някои интересни неща, за които малко хора знаят. Например как да търсите класации - официални и неофициални.

В хранилището github.com/helm/charts сега има около 300 графики и два потока: стабилен и инкубатор. Всеки, който допринася, знае много добре колко трудно е да се стигне от инкубатор до конюшня и колко лесно е да се излети от конюшня. Въпреки това, това не е най-добрият инструмент за намиране на диаграми за Prometheus и каквото друго искате, поради една проста причина - това не е удобен портал за търсене на пакети.

Но има услуга hub.helm.sh, с който е много по-удобно да намирате графики. Най-важното е, че има много повече външни хранилища и почти 800 налични чара. Освен това можете да свържете вашето хранилище, ако по някаква причина не искате да изпратите вашите диаграми в stable.

Опитайте hub.helm.sh и нека го разработим заедно. Тази услуга е в рамките на проект Helm и можете дори да допринесете за нейния потребителски интерфейс, ако сте интерфейс и просто искате да подобрите външния вид.

Искам също да обърна внимание на Open Service Broker API интеграция. Звучи тромаво и неразбираемо, но решава проблемите, с които се сблъсква всеки. Нека обясня с един прост пример.

Имаме клъстер Kubernetes, където искаме да стартираме класическо WordPress приложение. По правило е необходима база данни за пълна функционалност. Има много различни решения, например можете да стартирате своя собствена услуга с пълно състояние. Това не е много удобно, но много хора го правят.

Други, като нас в Chainstack, използват управлявани бази данни като MySQL или PostgreSQL за сървъри. Следователно нашите бази данни се намират някъде в облака.

Но възниква проблем: трябва да свържем нашата услуга с базата данни, да създадем вариант на базата данни, да предадем идентификационните данни и да я управляваме по някакъв начин. Всичко това обикновено се прави ръчно от системен администратор или разработчик. И няма проблем, когато има малко приложения. Когато има много от тях, имате нужда от комбайн. Има такъв комбайн - това е Service Broker. Тя ви позволява да използвате специален плъгин за публичен облачен клъстер и да поръчвате ресурси от доставчик чрез брокер, сякаш е API. За да направите това, можете да използвате собствените инструменти на Kubernetes.

Много е просто. Можете да поискате например управляван MySQL на Azure с базово ниво (това може да се конфигурира). Използвайки API на Azure, базата данни ще бъде създадена и готова за използване. Не е необходимо да се намесвате в това, плъгинът е отговорен за това. Например OSBA (Azure плъгин) ще върне идентификационните данни на услугата и ще ги предаде на Helm. Ще можете да използвате WordPress с облачен MySQL, изобщо да не се занимавате с управлявани бази данни и да не се тревожите за услугите с пълно състояние вътре.

Можем да кажем, че Helm действа като лепило, което от една страна ви позволява да разгръщате услуги, а от друга страна, консумира ресурсите на облачните доставчици.

Можете да напишете свой собствен плъгин и да използвате цялата тази история на място. Тогава просто ще имате свой собствен плъгин за корпоративния доставчик на облак. Съветвам ви да опитате този подход, особено ако имате голям мащаб и искате бързо да внедрите dev, staging или цялата инфраструктура за функция. Това ще улесни живота ви за вашите операции или DevOps.

Друга находка, която вече споменах, е плъгин helm-gcs, което ви позволява да използвате Google-кофи (съхранение на обекти) за съхраняване на Helm диаграми.

Имате нужда само от четири команди, за да започнете да го използвате:

1. инсталирайте плъгина;
2. инициирайте го;
3. задайте пътя до кофата, която е в gcp;
4. публикувайте диаграми по стандартния начин.

Хубавото е, че ще се използва собственият gcp метод за оторизация. Можете да използвате акаунт за услуга, акаунт на програмист, каквото и да е. Много е удобно и не струва нищо за работа. Ако вие, като мен, популяризирате философията без операции, тогава това ще бъде много удобно, особено за малки екипи.

алтернативи

Helm не е единственото решение за управление на услугата. Има много въпроси към него и вероятно затова третата версия се появи толкова бързо. Разбира се, има алтернативи.

Това могат да бъдат или специализирани решения като Ksonnet или Metaparticle. Можете да използвате вашите класически инструменти за управление на инфраструктура (Ansible, Terraform, Chef и т.н.) за същите цели, които споменах.

Най-накрая има решение операторска рамкакоято набира популярност.

Operator Framework е основната алтернатива на Helm, на която трябва да обърнете внимание.

Той е по-роден от CNCF и Kubernetes, но бариерата за влизане е много по-висока, трябва да кодирате повече и да описвате манифестите по-малко.

Има различни добавки, като Draft, Scaffold. Те правят живота много по-лесен, например те опростяват цикъла за разработчиците да изпращат и изпълняват Helm за внедряване на тестова среда. Бих ги нарекъл овластители.

Ето визуална графика на това къде е всичко.

Абсцисата е нивото на вашия личен контрол върху случващото се, ординатата е нивото на нативност на Kubernetes. Helm версия 2 е някъде по средата. Във версия 3 не е огромна, но контролът и нивото на нативност са подобрени. Решенията на ниво Ksonnet все още са по-ниски дори от Helm 2. Въпреки това си струва да ги разгледате, за да разберете какво друго има на този свят. Разбира се, вашият конфигурационен мениджър ще бъде под ваш контрол, но той абсолютно не е естествен за Kubernetes.

Operator Framework е напълно естествен за Kubernetes и ви позволява да го управлявате много по-елегантно и стриктно (но имайте предвид нивото на влизане). По-скоро е подходящ за специализирано приложение и създаване на управление за него, а не за масова комбинация за опаковане на огромен брой приложения, използващи Helm.

Удължителите само леко подобряват контрола, допълват работния процес или отрязват ъглите на CI/CD тръбопроводи.

Бъдещи Хелмс

Добрата новина е, че идва Helm 3. Алфа версията на Helm 3.0.0-alpha.2 вече е пусната, можете да я изпробвате. Той е доста стабилен, но функционалността все още е ограничена.

Защо ви е необходим Helm 3? На първо място, това е история за Изчезването на Тилър, като компонент. Това, както вече разбирате, е огромна крачка напред, защото от гледна точка на сигурността на архитектурата всичко е опростено.

Когато беше създаден Helm 2, което беше по време на Kubernetes 1.8 дни или дори по-рано, много от концепциите бяха незрели. Например концепцията CRD сега се прилага активно и Helm ще го направи използвайте CRDза съхранение на структури. Ще може да се използва само клиентската част и да не се запазва сървърната част. Съответно използвайте собствените команди на Kubernetes за работа със структури и ресурси. Това е огромна стъпка напред.

Ще се появи поддръжка за оригинални OCI хранилища (Инициатива за отворени контейнери). Това е огромна инициатива и Хелм се интересува предимно, за да публикува своите класации. Стига се дотам, че например Docker Hub поддържа много OCI стандарти. Не предполагам, но може би класическите доставчици на хранилища на Docker ще започнат да ви позволяват да хоствате техните диаграми на Helm.

Спорна история за мен е Поддръжка на Lua, като машина за шаблони за писане на скриптове. Не съм голям фен на Lua, но ще бъде напълно незадължително. Проверих го 3 пъти - използването на Lua няма да е необходимо. Така че, който иска да може да използва Lua, който харесва Go, присъединете се към нашия огромен лагер и използвайте go-tmpl за това.

И накрая, това, което определено ми липсваше, беше външен вид на схемата и валидиране на типовете данни. Няма да има повече проблеми с int или string, няма нужда да поставяте нула в двойни кавички. Ще се появи JSONS схема, която ще ви позволи изрично да опишете това за стойности.

Ще бъде сериозно преработен управляван от събития модел. Вече е концептуализирано. Погледнете клона на Helm 3 и ще видите колко събития и кукички и други неща са добавени, което значително опростява и от друга страна добавя контрол върху процесите на внедряване и реакциите върху тях.

Helm 3 ще бъде по-лесен, по-безопасен и по-интересен, не защото не харесваме Helm 2, а защото Kubernetes става все по-напреднал. Съответно Helm може да използва разработките на Kubernetes и да създава отлични мениджъри за Kubernetes върху него.

Друга добра новина е, че DevOpsConf Ще разкаже Александър Хайоров могат ли контейнерите да бъдат безопасни? Припомняме, че конференцията за интегрирането на процесите на разработка, тестване и експлоатация ще се проведе в Москва 30 септември и 1 октомври. Можете още до 20 август подадете доклад и разкажете за вашия опит един от много задачи на подхода DevOps.

Следете контролните точки на конференцията и новините пощенски списък и телеграм канал.

Източник: www.habr.com