Хмарний вітрильник

🔐 Секрети в Kubernetes: Що потрібно знати? 🫣Часто бувають випадки, коли треба використовувати певним контейнерам спеціальні креди, наприклад, для доступу до бази даних або ж до S3 бакета. Просто вкладати ці креди в умовний .env файл надто ризикована ідея. Тому кубер має таку штуку під назвою секрети (secrets) — вони використовуються для зберігання та управління конфіденційною інформацією, такою як паролі, токени доступу та ключі SSH. Вони дозволяють безпечно передавати ці дані у поди без включення їх у маніфести або конфігураційні файли Наприклад, щоб створити секрет можна застосувати kubectl:

kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secret

А потім цей секрет використати в поді:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    env:
    - name: USERNAME
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: username
#Дані повинні бути закодовані у base64

😎Звичайно, це тільки база для створення секюрності вашої інфраструктури на кубері, більш просунуті методи ми розповімо пізніше, але ось вам додатково ще кілька корисних порад як поводитись із секретам: 🔹Використовуйте Role-Based Access Control (RBAC) для обмеження доступу до секретів. 🔹Шифруйте секрети на рівні etcd. 🔹Регулярно ротуйте секрети. ☁️Хмарний вітрильник☁️

👋Всім привіт! Може хто знає, а може ні, але у Києві 15 червня відбудеться Highload fwdays'24 — унікальну та єдину в Україні конференцію від Fwdays, присвячену практичним питанням розробки високонавантажених систем, архітектури, масштабування, роботи з базами даних, DevOps 🙌 Детальна інформація на сайті 👉 https://bit.ly/3Knd7be Також використайте промокод DABCAB58C9 та отримайте знижку 10% Приєднуйтесь до Highload fwdays'24! Будемо вас там чекати👉

👩‍💻Що таке etcd у Kubernetes? Минулого разу ми розповіли про компоненти control plane в кубері, виконуємо свою обіцянку і потроху розповідаємо про його компоненти, і перший з них — etcd. etcd — це розподілена база даних формату ключ-значення з відкритим кодом, яка служить основним сховищем даних для Kubernetes. Які це саме дані? Це інформація про стан кластера, включаючи конфігурацію, стан подів, сервісів та інші метадані. Тобто пам'ятаєте ви завжди використовуєте yaml маніфести? Приблизно в такому ж вигляді зберігається увесь ваш стан кубера в etcd. Тому не дивно буде, що якщо ляже така БДшка, ляже і кластер, тому якщо ви не юзаєте клауд рішення аля EKS або AKS, радимо зробити наступні речі: а) Реплікація: розподіл даних на кількох вузлах (рекомендується непарна кількість вузлів: 3, 5 тощо). б) Резервні копії: регулярне створення резервних копій бази даних. в) Моніторинг: використовуйте інструменти моніторингу, такі як Prometheus для стеження за станом БД + налаштування алертингу. Також для менеджингу etcd корисно використовувати тулу etcdctl, а як нею користуватись можете подивитись у доці Як бачите, під капотом кластера можуть знаходитись дуже цікаві компоненти☺️ ☁️Хмарний вітрильник☁️

До минулого поста, ось так виглядає приблизна структура контрол плейну в кубері. Це досить спрощений варінат, але тим не менш для наочності) ☁️Хмарний вітрильник☁️

🔧 Kubernetes control plane: основні компоненти та їх роль Kubernetes (K8S) - це потужний інструмент для оркестрації контейнерів, який надає можливість автоматизувати розгортання, масштабування та керування контейнеризованими застосунками. У центрі цієї системи стоїть Control Plane, який забезпечує координацію всіх процесів у кластері. Як правило Control Plane розгорнутий на мастер нодах і їх може бути кілька щоб збільшити надійність кластеру. Сам control plane складається з наступних компонентів: 🔸etcd — зберігає стан кластера та конфігурацію 🔹kube-apiserver — по суті API для керування кластером (коли пишете kubectl команди ви саме звертаєтесь до АРІ кластера) 🔸kube-scheduler — відповідає за розміщення подів на ноди кластера 🔹kube-controller-manager — менеджер різноманітних контролерів Ці компоненти працюють разом, щоб забезпечити надійність, масштабованість і ефективність вашого Kubernetes-кластера, але про кожний окремо ми поговоримо у наступних постах. Якщо ви хочете більше постиків про компоненти контрол плейну — підтримайте лайком☺️ ☁️Хмарний вітрильник☁️

Чи ділити енви по неймспейсам чи по кластерам в кубернетесі? Як відомо, для бізнес цілей ми розбиваємо продукт по різним середовищам: дев та прод (як мінімум, ще може бути окремо стейдж, тест середовище і таке інше. тот політ фантазії насправді необмежений). І при роботі з кубером виникає питання: а як краще ці середовища реалізувати: умовно все в одному кластері поділене на неймспейси або в різних кластерах? Як завжди, в таких концептуальних питаннях одної відповіді нема, тут треба розуміти масштаби проекту. 🙂Розбиття по кластерам вигідно, коли ми хочемо отримати максимальну ізоляцію ресурсів різних середовищ, щоб не було ситуації "ой, я не в той неймспейс задеплоїв..." або коли треба оновити кубер, і в тебе одразу всі енви лежать (ну або в принципі коли кластер ліг). 🙃З іншої сторони, розбиття тупо по неймспейсам (тобто один кластер) вигідно в тому випадку, що не треба заморочуватись над обслуговуванням + дешевше кост (якщо ми говоримо, наприклад про EKS). ‼️Однак точно що ми можемо сказати. так це те, що середовище проду робити варто робити окремим. Чому? Тому що ви для бізнесу забезпечуєте надійність саме продакшн сервісів і ви можете тестувати інфраструктурні або софтварні фічі не боючись покласти прод. А ви що думаєте з цього приводу? Пишіть у коментарі! ☁️Хмарний вітрильник☁️

Нещодавно найшов для себе хорошу тулу для моніторингу та адміністрування контейнерів — Portainer. Прикольний він тим, що його можна запустити з пінка і при цьому він матиме нормальний Web UI. +його можна зробити централізований моніторинг, тобто наприклад один сервер центральний для моніторингу, а інші конектяться через портейнер агент Ну і цю аля моніторилку можна інтегрувати з кубером, але я цього ще не тестив. Там є багато прикольних фіч аля адміністрування юзерів, але це все у платній версії, тож в цілому для маленьких проектів де треба швидко і просто розгорнути мінімальний і прости логінг — інструмент доволі корисний А ви пробували юзати цей інструмент? Чи може у вас є якісь кращі аналоги? ☁️Хмарний вітрильник☁️

#memes А як ви навішуєте теги на докер імеджі?) ☁️Хмарний вітрильник☁️

#kubernetes Дуже цікава стаття на тему того, як правильно підібрати розмір ноди для подів. В основному розглядали два варіанти: або "одна нода = одна нода" або "одна велика нода для багатьох под". З власного досвіду можу сказати, що якщо мова йде про амазон, то там всі інстанси (ну або принаймні більшість) кратні по розмірам і по ціні, тож з точки зору ціни нема різниці, чи візьмете ви три маленьких інстанси замість одного еквівалентно великого. Однак якщо всі поди прям тримати на одній-двох великих інстансах, то можуть виникнути проблеми з менеджментом ресурсів, але і тут можна виграти у швидшому розгортанні мікросервісів (бо розгортається тільки под. а не под та інстанс). Коротше, рекомендуємо чтиво👇👇👇 https://learnk8s.io/kubernetes-node-size ☁️Хмарний вітрильник☁️

Доречі, про вчорашню тему є кілька цікавих матеріалів, хотів би з вами ними поділитись: 1. Бест практіс по БД на кубері 2. Есе на тему чи треба ставити БД на кубер (спойлер: автор думає що ні) ☁️Хмарний вітрильник☁️

Бази даних у кубері чи на RDS? 🥴Часто серед комьюніті девопс виникає досить екзистенційне питання, де краще ставити БДшку — десь на RDS (чи просто на ЕС2) або ж все це діло розписати як маніфест файли і розгорнути в кубері? 🤨Для тих хто не в темі, це питання гостро стоїть по тій причині, що взагалі кубер ідеально підходить для stateless сервісів (тобто там де сервісу не треба зберігати дані): можливість автоскейлингу, деплоймент стратегій, авторестартів, ромзноження реплік, автобалансинг ітд ітп робить кубер ідеальною тулою для розгортання подібних сервісів. 😣Водночас бази даних вимагають найкращої надійності та безпеки: наприклад щоб под з базою даних не ставився куди попало, а в потрібний інстанс з оптимізованим під І/О диском достатнього розміру. 🤔В принципі, побоювання окремих інженерів зрозуміла: динамічність куберу в розумінні БД є досить ризикованою справою, однак є маса інструментів для того, щоб кубер кластер міг нормально хендлити бази даних. Наприклад, якщо треба щоб база даних стояла тільки в конкретних інстансах, можна юзати taints та tolerations, а якщо треба забезпечити скейлінг по І/О, то можна як у Mongo DB юзати шардінг. Окрім того. існує сила силенна операторів для інтеграції БД в кубер. По суті щоб правильно оцінити чи має сенс ставити БД на кубер, треба спочатку для себе відповісти на наступні питання: 1. Що це за база даних та навіщо вона потрібна? — Якщо це для кешування аля редісу, то тут взагалі без проблем можна ставити на кубер як сайд кар для сервісу. Якщо ж це постгре для даних кастомерів, то тут вже трохи інше питання. 2. Чи є у вас достатньо навичок та часу, щоб забезпечити стабільну роботу застосунку? — Іноді простіше та дешевше розгорнути БД на RDS ніж потім місяцями возитись та мейнтенити самостійно БД на кубері. 3. (Напевно головне): який масштаб проекту? — Якщо проект невеликий і вас не дуже цікавить швидкість І/О, то не треба морочити собі голову і розгорніть на RDS це діло. А у вас який досвід був з розгортанням БД? Що ви про це скажете? ☁️Хмарний вітрильник☁️

Доречі, на наступному тижні стартує нова група по менторству, залишилось 2 місця. За подробицями - пишіть мені в особисті @eugene_koshmanov

+1 в ДевОпс клубі!🚀