Същността на разказа за най-популярния пакетен мениджър за Kubernetes може да бъде изразена чрез емоджи:
- кутия — това е Helm (най-подходящото, което има в последната версия на Emoji);
- катинар — безопасност;
- човечец — решение на проблема.
Всъщност обаче, всичко ще бъде малко по-сложно, а разказът е пълен с технически подробности за това, как да направим Helm безопасен.
- Накратко, какво представлява Helm, ако не сте знаели или сте забравили. Какви проблеми решава и къде се намира в екосистемата.
- Нека разгледаме архитектурата на Helm. Нито един разговор за безопасност и за това как да направим инструмента или решението по-безопасно не може да мина без разбиране на архитектурата на компонента.
- Нека обсъдим компонентите на Helm.
- Най-наболелият въпрос — бъдещето — новата версия Helm 3.
Всичко в тази статия се отнася до Helm 2. Тази версия в момента е в производство и вероятно точно нея използвате в момента, и точно в нея има заплахи за безопасността.
За говорителя: Александър Хаёров () е разработчик от 10 години, помага да се подобри съдържанието и се присъедини към комитета . В момента работи в Chainstack на позиция на ръководител на разработката — това е хибрид между ръководител на разработка и човек, който отговаря за доставката на крайните версии. Тоест, той е на бойното поле, където протича всичко от създаването на продукта до неговата експлоатация.
Chainstack — малък, активно растящ стартап, чиято задача е да предложи на клиентите възможността да забравят за инфраструктурата и сложностите на управлението на децентрализирани приложения, а екипът за разработка е в Сингапур. Не поискайте от Chainstack да продава или купува криптовалута, а предложете да поговорят за корпоративни блокчейн рамки, и те с радост ще отговорят.
Helm
Това е пакетен мениджър (чартове) за 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 вече представлява няколко услуги, и е нужно да бъдат пакетирани заедно.
- Управление на сложността, която възниква с управлението на тези приложения.
- Жизнен цикъл, който не приключва след инсталирането или разполагането на приложението. То продължава да съществува, трябва да се обновява и в това Helm помага, стараейки се да предостави правилните мерки и политики.
Пакетиране е устроено по разбираем начин: има метаданни в съответствие с работата на обикновен пакетен мениджър за Linux, Windows или MacOS. Тоест, репозитории, зависимости от различни пакети, метаинформация за приложения, настройки, особености на конфигурирането, индексиране на информация и др. Всичко това Helm позволява да се получи и използва за приложения.
Управление на сложността. Ако имате много сходни приложения, необходима е параметризация. От това произтичат шаблони, но за да не измисляте собствен начин за създаване на шаблони, можете да използвате това, което Helm предлага от самото начало.
Управление на жизнения цикъл на приложението за мен е най-интересният и нерешен въпрос. Това е причината, поради която се насочих към Helm. Трябваше да следим жизнения цикъл на приложението, искахме да пренесем нашия CI/CD и цикли на приложения в тази парадигма.
Helm позволява:
- да управлява разполагания, въвежда понятието конфигурация и ревизия;
- успешно да извършва rollback;
- да използва хукове за различни събития;
- да добавя допълнителни проверки на приложенията и да реагира на техните резултати.
Освен това в Helm има «батерии» — огромно количество вкусни неща, които можете да включите като плъгини, опростявайки живота си. Плъгините могат да се пишат самостоятелно, те са достатъчно изолирани и не изискват ясна архитектура. Ако искате да реализирате нещо, препоръчвам да го направите като плъгин, а след това може би да го включите в upstream.
Helm се основава на три основни концепции:
- Chart Repo — описание и масив от параметри, възможни за вашия манифест.
- Конфигурация — тоест стойности, които ще бъдат приложени (текст, числови стойности и т.н.).
- Release събира два горни компонента, и те заедно се превръщат в Release. Релизите могат да бъдат версионирани, като по този начин постигате организация на жизнения цикъл: малък при инсталация и голям при актуализиране, понижаване или възстановяване.
Архитектура на 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.
Нека обсъдим всичките тези направления последователно.
RBAC
Безполезно е да говорим за безопасността на Helm или на друга услуга в клъстера, ако не е активиран RBAC.
Изглежда, това не е най-новото препоръка, но съм сигурен, че все още мнозина не са активирали RBAC дори в продукцията, тъй като това е голямо занимание и изисква много настройки. Въпреки това, призовавам да го направите.
— сайт адвокат за RBAC. Там е събрано огромно количество интересни материали, които ще помогнат за настройването на RBAC, ще покажат защо е добър и как изобщо да се живее с него в продукция.
Ще се опитам да обясня как работи Tiller и RBAC. Tiller работи вътре в клъстера под някакъв сервисен акаунт. Обикновено, ако RBAC не е настроен, това ще бъде суперпотребител. В базовата конфигурация Tiller ще бъде администратор. Затова често казват, че Tiller е SSH тунел към вашия клъстер. В действителност е така, затова можете да използвате отделен специализиран сервисен акаунт вместо Default Service Account на схемата по-горе.
Когато инициирате Helm, за първи път го инсталирате на сървъра, можете да зададете сервисен акаунт с помощта на --service-account. Това ще позволи да се използва потребител с минимално необходим набор от права. Истината е, че ще трябва да създадете такава "гирлянда": Role и RoleBinding.
За съжаление, Helm няма да го направи за вас. Вие или вашият администратор на Kubernetes клъстера трябва предварително да подготвите набор от Role и RoleBinding за сервисния акаунт, за да предадете на 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 с контекст за различни екипи (две пространства на имена): X Team за екипа на разработчиците и клъстера на администратора. Клъстерът на администратора има своя собствена широка Tiller, която се намира в пространството на Kube-system namespace, съответно разширен service-account. И отделно пространство за имена за екипа на разработчиците, те ще могат да разполагат своите услуги в специално пространство.
Това е работещ подход, Tiller не е толкова ненаситен, за да повлияе значително на вашия бюджет. Това е едно от бързите решения.
Не се колебайте да настройвате отделно Tiller и да предоставяте Kubeconfig с контекст за екипа, за конкретен разработчик или за среда: Dev, Staging, Production (малко е вероятно всичко да е на един клъстер, но е възможно).
Продължавайки нашата история, ще преминем от RBAC и ще поговорим за ConfigMaps.
ConfigMaps
Helm използва ConfigMaps като хранилище на данни. Когато говорихме за архитектурата, там не беше посочена база данни, в която да се съхранява информация за релизи, конфигурации, rollbacks и т.н. За това се използват ConfigMaps.
Основният проблем с ConfigMaps е известен — те не са сигурни по принцип, в тях невъзможно е да се съхраняват sensitive-данни. Става въпрос за всичко, което не трябва да излиза извън услугата, например, пароли. Най-нативният начин за Helm в момента е да преходи от използването на ConfigMaps към секрети.
Това става много лесно. Преопределяте настройката на Tiller и указвате, че хранилището ще бъдат секрети. Тогава за всяко разполагане ще получавате не ConfigMap, а секрет.
Може да възразите, че самите секрети — странна концепция, и това не е много безопасно. Въпреки това, трябва да разберете, че това се управлява от самите разработчици на Kubernetes. От версия 1.10, т.е. от доста време, има възможност, поне в публичните облаци да се включи правилното хранилище за съхранение на секрети. Сега екипът работи върху това, за да даде достъп до секретите, на отделни подове или други обекти.
Съхранението на 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 и базова автентикация;
- mTLS за Tiller, и той е изложен като gRPC услуга с TLS, използваме сертификати;
- в клъстера се използва специален сервис акаунт с Role и RoleBinding.
Успяхме значително да обезопасим клъстера, но някой умен каза:
„Абсолютно безопасно решение може да бъде само едно — изключен компютър, който се намира в бетонна кутия и е охраняван от войници“.
Има различни начини за манипулиране на данни и откриване на нови вектори на атака. Въпреки това, уверявам се, че тези препоръки ще позволят реализирането на основен индустриален стандарт за безопасност.
Бонус
Тази част не е пряко свързана с безопасността, но също така ще бъде полезна. Ще покажа някои интересни неща, които малко хора знаят. Например, как да търсите чартове — официални и неофициални.
В репозитория в момента има около 300 чартове и два стрима: stable и incubator. Този, който контрибютва, знае колко трудно е да попадне от incubator в stable и колко лесно е да излезе от stable. Въпреки това, това не е най-добрият инструмент за търсене на чартове за Prometheus и всичко, което ви харесва, по една проста причина — не е портал, където удобно да търсите пакети.
Но има услуга , с която намирането на чартове е много по-удобно. Най-важното е, че там има много повече външни репозитории и са налични почти 800 чарта. Освен това, можете да свържете своя репозиторий, ако по някакви причини не искате да изпращате своите чартове в stable.
Опитайте hub.helm.sh и нека го развиваме заедно. Тази услуга е под проект на Helm и можете да допринасяте дори в потребителския интерфейс, ако сте фронтенд разработчик и искате просто да подобрите визията.
Искам също да обърна вниманието ви на интеграцията на Open Service Broker API. Звучи сложно и неясно, но решава проблеми, с които всички се сблъскват. Ще обясня с прост пример.
Има Kubernetes клъстер, в който искаме да стартираме класическо приложение — WordPress. Обикновено е необходима база данни за цялостна функционалност. Има много различни решения, например, можете да стартирате свой stateful сървис. Това не е много удобно, но много хора правят точно това.
Други, например ние в Chainstack, използват управлявани бази данни, като MySQL или PostgreSQL, за сървърите. Затова нашата база данни се намира някъде в облака.
Но възниква проблем: необходимо е да свържете услугата с базата данни, да създадете flavor на базата данни, да предадете данните за достъп и по някакъв начин да ги управлявате. Всичко това обикновено се прави ръчно от системен администратор или разработчик. И няма проблем, когато има малко приложения. Когато приложенията са много, е необходим комбайн. Такъв комбайн е Service Broker. Той позволява да се използва специален плъгин към кластера на публичния облак и да се поръчват ресурси от доставчика чрез Broker, сякаш става въпрос за API. За това могат да се използват местните средства на Kubernetes.
Това е много просто. Можете да поискате, например, Managed MySQL в Azure с базов tier (това може да бъде конфигурирано). С помощта на Azure API базата ще бъде създадена и подготвена за използване. Няма да ви се наложи да се намесвате, плъгинът отговаря за това. Например, OSBA (плъгин за Azure) ще върне данните за достъп на услугата и ще ги предаде на Helm. Ще можете да използвате WordPress с облачен MySQL, без да се ангажирате с управлявани бази данни и без да се притеснявате за stateful сървиси в системата.
Може да се каже, че Helm действа като лепило, което от една страна позволява да се разгръщат услуги, а от друга — да се използват ресурси от облачни доставчици.
Можете да напишете свой плъгин и да използвате всичко това on-premise. Тогава ще имате свой собствен плъгин за корпоративния облачен доставчик. Препоръчвам да опитате този подход, особено ако имате голям мащаб и искате бързо да развернете dev, staging или цялата инфраструктура за нова функция. Това ще улесни живота на вашите операции или DevOps.
Още едно откритие, което вече споменах — това е плъгинът helm-gcs, който позволява да използвате Google-buckets (обектно хранилище), за да съхранявате Helm-чарти.
Нужни са само четири команди, за да започнете да го използвате:
- инсталирайте плъгинa;
- инициирайте го;
- заданието на пътя към bucket, който се намира в gcp;
- публикувайте чартите по стандартен начин.
Красотата е, че ще се използва нативният начин на gcp за авторизация. Можете да използвате сервисен акаунт, акаунт за разработчици - всичко, което искате. Това е много удобно и не струва почти нищо в експлоатация. Ако, като мен, пропагандирате философията без ops, то това ще бъде много удобно, особено за малки екипи.
Алтернативи
Helm не е единственото решение за управление на услуги. Имам много въпроси към него, вероятно затова бързо се появи трета версия. Разбира се, има алтернативи.
Те могат да бъдат или специализирани решения, като Ksonnet или Metaparticle. Можете да използвате вашите традиционни инструменти за управление на инфраструктурата (Ansible, Terraform, Chef и др.) за същите цели, за които говорех.
Накрая, има решение , чиято популярност расте.
Operator Framework е основната алтернатива на Helm, на която трябва да обърнете внимание.
То е по-нативно за CNCF и Kubernetes, но прага за влизане е значително по-висок, нужно е повече програмиране и по-малко описване на манифести.
Съществуват различни добавки, като Draft, Scaffold. Те значително улесняват живота, например, на разработчиците, като опростяват цикъла на изпращане и стартиране на Helm за деплой на тестова среда. Бих ги нарекъл разширители на възможностите.
Ето наочен график за това, къде какво се намира.
По абсцисата е вашето ниво на личен контрол над събитията, по ординатата - нивото на натуралност на Kubernetes. Helm версия 2 е някъде по средата. В версия 3 не е коронално, но контролът и нивото на натуралност са подобрени. Решенията от нивото на Ksonnet все пак отстъпват на дори Helm 2. Но определено си заслужават, за да знаете какво още има в този свят. Разбира се, вашият конфигурационен мениджър ще бъде под ваш контрол, но абсолютно не е нативен за Kubernetes.
Операторската рамка е напълно нативна за Kubernetes и позволява да се управлява много по-елегантно и прецизно (но да помним за нивото на достъп). По-скоро, това е подходящо за специализирано приложение и създаване на управление за него, отколкото за масов комбайн за опаковане на огромно количество приложения с помощта на Helm.
Разширителите просто малко подобряват контрола, допълват работния процес или задължават CI/CD пайплайни.
Бъдещето на 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, като шаблонен двигател за писане на скриптове. Не съм голям фен на Lua, но това ще бъде напълно опционална възможност. Проверих това три пъти - използването на Lua няма да е задължително. Следователно, който иска, може да използва Lua, а който предпочита Go - присъединявайте се към нашия огромен лагер и използвайте go-tmpl за това.
Най-накрая, това, което определено ми липсваше, е появата на схема и валидация на типовете данни. Вече няма да има проблеми с int или string, не е нужно да увивате нулата в двойни кавички. Ще се появи JSONS-схема, която ще позволи ясно да се опише това за values.
Ще бъде много сериозно преработена моделът, базиран на събития. Тя вече е концептуално описана. Разгледайте клона Helm 3 и ще видите колко много събития, хукове и др. са добавени, което значително ще опрости и, от друга страна, ще добави контрол върху процесите на деплой и реакциите по тях.
Helm 3 ще бъде по-лесен, по-сигурен и по-интересен не защото не обичаме Helm 2, а защото Kubernetes става все по-напреднал. Съответно, Helm може да използва напредъка на Kubernetes и да създава отлични мениджъри за Kubernetes.
Още една добра новина е, че на Александър Хаёров ще разкаже Напомняме, че конференцията по интеграция на процесите на разработка, тестване и експлоатация ще се проведе в Москва на 30 септември и 1 октомври. До 20 август все още можете да и да разкажете за своя опит в решаването на задачи от DevOps подхода.
Следете за чекпойнтовете на конференцията и новините в и .
Източник: habr.com
