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