Ще одна крута фіча, яку Амазон показав ще на минулому re:Invent в листопаді 2023 – це зміни в тому, як AWS Elastic Kubernetes Service виконує аутентифікацію та авторизацію юзерів. При чому це стосується не тільки саме користувачів кластеру, а і WorkerNodes.
Тобто, не дуже-то нова схема – але в мене ось тільки зараз дійшли руки до апгрейду кластеру з 1.28 на 1.30, заодно буду оновлювати версію модулю terraform-aws-modules/eks зі змінами ESK Access Management API, бо зараз ми на версії 19, а зміни були додані в версії 20 (див. v20.0.0 Release notes),
Про Terraform, мабуть, поговоримо в наступному пості, а сьогодні давайте глянемо як нова система працює, і що вона нам дозволяє. А вже знаючи це – візьмемо Terraform, і взагалі подумаємо про те, як організувати роботу з IAM з урахування змін в EKS Access Management API та EKS Pod Identities.
Загалом по аутентифікації/авторизації в Kubernetes можна ще глянути старі пости:
Раніше ми мали спеціальний aws-auth ConfigMap, в якому описувались WorkerNodes IAM Roles, всі наші юзери та їхні групи.
Відтепер, ми можемо керувати доступами в EKS напряму через його API використовуючи AWS IAM в ролі аутентифікатора. Тобто, юзер логіниться в AWS, AWS виконує аутентифікацію – перевіряє, що це саме той юзер, за якого він себе видає, а потім, коли юзер підключається до Kubernetes – то виконується його авторизація – перевірка прав доступу до кластеру і в самому кластері.
При цьому ця схема чудово працює з RBAC самого Kubernetes.
І ще одна дуже важлива деталь – що ми нарешті можемо позбутись “дефолтного root-юзера” – прихованого адміністратора кластера, від імені якого він створювався. При чому раніше ми не мали змоги ніде його побачити або змінити, що іноді спричиняло проблеми.
Отже, якщо раніше нам потрібно було самим керувати записами в aws-auth ConfigMap, і не дай боже його зламати (а в мене траплялось через чи то кривий маніфест, чи то не дуже прямі руки) – то тепер ми можемо винести управління доступами в окремий Terraform-код, і управляти доступами набагато простіше і з меншим ризиком.
Зміни в IAM та EKS
Тепер у нас в EKS є дві нові сутності – Access entries та Access policies:
Amazon EKS Access Entries – запис в EKS про об’єкт, який пов’язаний з AWS IAM роллю чи юзером
описує тип (звичайний юзер, EC2, etc), Kubernetes RBAC Groups, або EKS Access Policy
Amazon EKS Access Policy – політика в EKS, яка описує права для EKS Access Entries. І це політики саме EKS – ви не знайдете їх в IAM.
Підозрюю, що десь під капотом ці EKS Access Policy просто мапляться на Kubernetes ClusterRoles.
Ці політики ми підключаємо до IAM Role чи IAM user, і під час підключення до Kubernetes-кластеру EKS Autorizer перевіряє які саме права є у цього користувача.
Замість дефолтних AWS managed IAM Policy ми при створенні EKS Access Policy можемо вказати ім’я Kubernetes RBAC Group – і тоді замість EKS Autorizer буде використано механізм Kubernetes RBAC – далі подивимось, як це працює.
Для Terraform в terraform-provider-aws версії 5.33.0 були додані два нових відповідних типи resource – aws_eks_access_entry та aws_eks_access_policy_association. Але зараз все будемо робити руками.
Налаштування Cluster access management API
Перевіряти як воно працює будемо на існуючому кластері версії 1.28.
Зараз у нас включено ConfigMap (той самий aws-auth) – міняємо на EKS API and ConfigMap – так ми залишимо і старий механізм, і протестуємо новий (в Terraform це також можна зробити):
Звертаємо увагу на попередження “Once you modify a cluster to use EKS access entry API, you cannot change it back to ConfigMap only” – але terraform-aws-modules/eks версії 19.21 ці зміни ігнорує і нормально працює далі, тож можна міняти руками.
Тепер кластер буде виконувати авторизацію юзерів і з aws-auth ConfigMap, і з EKS Access Entry API, з перевагою до Access Entry API.
Після переключення на EKS Access Entry API відразу маємо нові EKS Access Entries:
І як раз тепер ми можемо побачити того самого “прихованого root-юзера” – assumed-role/tf-admin, бо Teraform працює саме від цієї IAM-ролі, і в моєму сетапі це робилось як через цей механізм EKS, від якого тепер можна буде позбутись.
Але з поточного aws-auth ConfigMap взято не все – роль для WorkerNodes є, а от решта записів (юзери з mapUsers та ролі з mapRoles) автоматично не додались. Хоча під час зміни параметра API_AND_CONFIG_MAP через Teraform це наче має відбутись – потім перевіримо.
З юзером закінчили – тепер треба з ним підключитись до кластеру.
EKS: створення Access Entry
Можемо зробити або через AWS Console:
Або з AWS CLI (з робочим профайлом, а не новим, бо в нього ніяких прав нема) і командою aws eks create-access-entry.
В параметрах передаємо ім’я кластера та ARN юзера чи ролі, яких підключаємо до кластеру (але, мабуть, більш коректно буде сказати “для яких створюємо точку входу на кластер“, бо сутність називається Access Entry):
Зверніть увагу на --access-scope type=cluster – зараз ми видали ReadOnly права на весь кластер, але можемо обмежити конкретним неймспейсом(ми) – далі спробуємо.
Глянемо ще раз в AWS Console:
Access Policy додано.
Пробуємо kubectl:
$ kubectl auth can-i get pod
yes
Але не можемо створити под – бо маємо ReadOnly права:
На майбутнє, відключити створення такого юзеру при створенні кластера з aws eks create-cluster можна параметром bootstrapClusterCreatorAdminPermissions=false.
А зараз давайте замінимо його – додамо нашому тестовому юзеру адмін-права і видалимо дефолтного root.
Повторяємо aws eks associate-access-policy, але тепер в --policy-arn вказуємо AmazonEKSClusterAdminPolicy:
$ aws --profile work eks delete-access-entry --cluster-name atlas-eks-test-1-28-cluster --principal-arn arn:aws:iam::492***148:role/tf-admin
Namespaced EKS Access Entry
Замість того, аби видавати права на весь кластер з --access-scope type=cluster – ми можемо зробити юзера адміном тільки у конкретних неймспейсах.
Не відключаємо нашого тестового юзера – бо наразі це наш єдиний адмін. Давайте візьмемо звичайного IAM User, то зробимо його адміном тільки в одному Kubernetes Namespace.
Створюємо новий неймспейс:
$ kk create ns test-ns
namespace/test-ns created
Створюємо нову EKS Access Entry для мого AWS IAM User:
$ aws --profile work eks create-access-entry --cluster-name atlas-eks-test-1-28-cluster --principal-arn arn:aws:iam::492***148:user/arseny
І підключаємо AmazonEKSEditPolicy, але в --access-scope задаємо тип namespace та вказуємо ім’я цього NS:
В access-scope ми можемо задати або clutser, або неймспейс. Не дуже гнучко – але для гнучкості у нас є RBAC.
Генеруємо новий kubectl context з --profile work, де profile work – мій звичайний AWS User, для якого ми створювали EKS Access Entry з AmazonEKSEditPolicy:
$ aws --profile work eks update-kubeconfig --name atlas-eks-test-1-28-cluster --alias test-cluster-arseny-user
Updated context test-cluster-arseny-user in /home/setevoy/.kube/config
І перевіряємо права – спочатку в default Namespace:
$ kubectl --namespace default auth can-i create pod
no
І в тестовому неймспейсі:
$ kubectl --namespace test-ns auth can-i create pod
yes
Nice!
Все працює.
EKS Access Entry та Kubernetes RBAC
Замість того, щоб підключати EKS Access Policy від AWS, яких всього чотири – ми можемо використати звичайний механізм Kubernetes Role-Based Access Control, RBAC.
Це виглядає так:
в EKS створюємо Access Entry
в параметрах Access Entry вказуємо Kubernetes RBAC Group
а далі за звичною схемою – використовуємо RBAC Group та Kubernetes RoleBinding
Тоді ми пройдемо аутентифікацію в AWS, після чого AWS “передасть” нас до Kubernetes, а той вже виконає авторизацію – перевірку наших прав в кластері – на основі нашої RBAC-групи.
Видаляємо створену Access Entry для мого IAM User:
$ aws --profile work eks delete-access-entry --cluster-name atlas-eks-test-1-28-cluster --principal-arn arn:aws:iam::492***148:user/arseny
Створюємо його заново, але тепер додаємо --kubernetes-groups:
Перший пост цієї “серії” (яка взагалі не планувалась як серія) – я написав ще у 2022, коли вперше довелося почати розбиратись з електрикою і тим, як забезпечити електрохарчування вдома під час відключень:
Цей пост я почав писати в кінці жовтня – на початку листопада 2023 року, коли готувався до зими, але недописав, та й зима пройшла без відключень.
Втім, раптом питання стало дуже актуальним влітку 2024 року – тож давайте повернемось до цієї теми.
Отже, про що будемо говорити:
згадаємо що таке вольти/ампери/вати
як порахувати потужність електроприладів вдома і прикинути необхідний запас енергії
як ми цей запас можемо тримати – які типи зарядних станцій та інших подібних рішень є
розглянемо питання, пов’язані з ДБЖ та інверторами – на що звертати увагу при виборі, як правильно користуватись
і поговоримо про акумулятори – які типи є, їхні характеристики, плюси-мінуси, і розглянемо питання зарядки
Відразу хочу нагадати, що я не електрик, а звичайний айтішник.
І цей пост – не “повний гайд” з точними рекомендаціями що вибрати і як налаштувати, а більше має на меті дати загальну інформацію по основним питанням.
Вольти: напруга – по суті схожа з величиною тиску води в трубі – чим він вище, тим с більшою силою йде вода з крана, тобто з якою “силою” електрони штовхаються через провідник. Позначається як В або V.
Ампер: сила струму – можна порівняти з кількістю води, що протікає через трубу за одиницю часу, або з кількістю даних, що передається через мережевий канал за одиницю часу (наприклад, кількість пакетів або бітів). В цьому випадку ампери визначають, скільки електричних зарядів проходить через провідник за одиницю часу.
Ват: потужність – можна порівняти з кількістю води в літрах, яке виллється з крана. Позначається як W (Вт).
Наприклад, якщо знаємо, що батареї EcoFlow працюють на 50 вольтах, а споживана потужність під час зарядки 2000 ват – то отримуємо силу струму зарядки у 2000/50 == 40 ампер. Але про це все будемо детальніше говорити далі.
Або навпаки: якщо зарядний пристрій працює на 12 вольтах і видає 10 ампер сили струму – то він передає 120 ват, а якщо 24 вольти на тих жеж 10 амперах – то вже 240 ват.
Ще досить гарне пояснення – побачив колись давно десь в коментарях на Ютубі, і мені воно прям дуже подобається:
– Напруга (V): ширина річки – Сила струму (A): швидкість течії води в річці Тому одну і ту ж потужність може дати й широка ріка (висока напруга, Вольт) з повільною течією (слабкий струм, Ампер) – і вузька річка (низька напруга, Вольт) зі швидкою течією (сильний струм, Ампер).
Чим швидше ріка і чим вона ширше – тим більше води (Ват) за одиницю часу.
Тобто:
Напруга (V) – ширина річки: широка річка може передати більше води при тій же швидкості течії (силі струму)
хоча ширина річки тут не дуже вдала аналогія, бо напруга (в вольтах) описує різницю електричних потенціалів, що штовхає електрони через провідник, подібно до того, як різниця висот штовхає воду вниз по річці
Сила струму (A) – швидкість течії води в річці:
умовна річка шириною в 10 метрів при швидкості течії води в 10 метрів на секунду передає 100 кубометрів води в секунду
умовна річка шириною в 100 метрів при швидкості течії води в 1 метр на секунду також передає 100 кубометрів води в секунду
Потужність (W) – кількість води за одиницю часу: потужність визначається як кількість енергії, переданої (або спожитої) за одиницю часу, і в цій аналогії це кількість води, що проходить через річку за певний проміжок часу (наші 100 кубометрів в секунду)
Потужність можна отримати за допомогою формули P=V×I, де P – потужність в ватах, V – напруга в вольтах, а I – сила струму в амперах.
Рахуємо потужність приладів вдома
Ми не будемо брати до уваги прилади по типу стиральної машини або кавоварки, бо під час відключення електроенергії ви навряд чи будете їх живити від батарей.
Але є така ось табличка, аби мати уявлення про потужність різних приладів:
Отже, що нам знадобиться? Рахуємо те, що має працювати постійно, тобто телевізор, ігрову приставку або ігровий ПК пропускаємо.
В моєму випадку це:
холодильник: 80 ват (маємо на увазі пусковий струм до х10 від номінального – але про це поговоримо, коли будемо розглядати інвертори та ДБЖ)
газовий котел для опалення і гарячої води для душа/кухні (у нас в ЖК свої скважини, насоси та генератори для них): 130 ват (і теж має пусковий струм, хоча тут, мабуть, поменше, бо нема компресора, як у холодильнику – тільки двигун насоса)
і “куточок користувача”:
настільна лампа: 8 ват
колонки: 10 ват
роутер: 18 ват
медіаконвертер (оптика => ethernet): 12 ват
монітор: 40 ват
ноутбук: 60 ват
Заміряти можна ватметром, наприклад мій холодильник:
Але холодильник і котел працюють не постійно, а вмикаються та вимикаються при потребі, коли змінюється температура. Давайте вважати, що вони працюють 50/50 від загального часу.
Тоді холодильник і котел працюючи одночасно споживають ~210 ват, умовно кажучи, годину через годину. Значить в розрахунок беремо 100 ват/годину.
Тепер додаємо решту – “куточок користувача”, і тут маємо ще ~150 ват/годин.
Отже, разом це 250 ват/годину – і тепер ми можемо рахувати необхідний запас.
Самий довгий блекаут 2022/2023 був три доби, а на добу нам потрібно:
холодильник і котел: працюють цілодобово, по 100 Вт/г – на добу потрібен запас у 2400 ват/годин
“куточок користувача”: працюють умовних 14 годин на добу, по 150 Вт/г – на добу потрібен запас у 2100 ват/годин
Тобто разом необхідний добовий запас енергії – 4500 ват/годин. Хоча взимку 2022/2023 я обходився без холодильника – м’ясо з морозильника вивішував в пакеті за вікном.
Тепер можна поговорити про те, як цей запас отримувати та зберігати.
Варіанти енергозабезпечення: зарядні станції, акумулятори, ДБЖ
Ну і тут вибір на всі смаки:
зарядні станції типу EcoFlow/Bluetti: найкращій варіант з точки зору безпеки та обслуговування, бо “it just works”, але і найдорожчий
саморобні станції від майстрів: дешевші від EcoFlow, прості в обслуговуванні, але є ризики що китайська начинка накриється, і станція перестане працювати, або можливі проблем з батареями (і навіть пожежа)
ДБЖ та акумулятори: більш складний варіант з точки зору зборки самої системи, більш небезпечний ніж EcoFlow (але безпечніший за саморобні станції), проте дешевше, ніш EcoFlow
окремо зарядне, інвертор та акумулятори: найскладніший з точку зору зборки системи та її обслуговування, і найбільш небезпечний при порушенні правил використання
Трохи окремо стоять сонячні батареї та генератори – але я про них писати не буду, бо живу у квартирі, і генератор ставити на балконі не можна, а сонячні батареї вішати хіба що за балкон – але тут є питання в їх ефективності, особливо взимку, бо балкон на захід, і питання їхнього монтажу – треба або шукати майстрів, а це не дуже просто, або робити самому – а в мене не настільки прямі руки.
Найбільші ризики використання всіх подібних приладів – це пожежа, і ці ризики треба мати на увазі, бо ми багато в новинах чуємо про черговий випадок вибухів на балконах.
Наприклад я собі “від гріха подалі” ще у 2022 купив два вогнегасники:
Ще – якщо дійдуть руки, буде час та натхнення – то хочу зробити з Adruino датчики тепла (міряти температуру на балконі, це стоять зарядні станції та акумулятори, і температуру самих акумуляторів), та датчик диму. Хоча можна просто купити готові рішення від того ж Ajax Systems.
Окей. Тепер давайте розберемо ці системи детальніше.
Зарядні станції EcoFlow/Bluetti/etc
Я їх не розглядав в минулих записах, бо в мене їх не було 🙂
Але в цьому році я все ж купив собі EcoFlow DELTA Max 2000 (2016 Вт·год). Обійшлася вона мені в ~59.000 грн (брав на Rozetka), і я вважаю, що воно того варте.
В мене Li-ion батареї, а аналогічна станція з LiFePo4 буде коштувати близько 100.000 (це зараз, при курсі долара ~40 грн). Про батареї будемо говорити окремо і детальніше далі, але в принципі LiFePo4 варті свої грошей.
Коли я себе вговорював купити її, то останнім було – “Блін, ти собі на день народження подарував Samsung S23 Ultra за 50.000 грн! І це просто телефон – а тут питання нормального функціювання!“.
Тобто – да, воно коштує грошей, і не мало, проте ви просто його вмикаєте – і спокійно собі живете.
Переваги:
простота: воно просто працює, і нічого в принципі від вас не вимагає
безпека: це, мабуть, максимальний рівень безпеки в плані як вибуху/пожежі, так і випадкового замикання дротів або удару током вас, як юзера
надійність: це, мабуть, максимальний рівень безпеки надійності з точки зору поломки – якщо правильно використовувати та не перенавантажувати
швидкість зарядки: це дуже важливий момент, і про нього будемо говорити далі, але щодо EcoFlow – то він свої 2000 Вт/год “заливає” за півтори години – і це дуже круто
мобільний додаток: керування параметрами та відображення даних по споживанню/запасу енергії – дуже зручно, дуже корисно
компактність: для розміщення такого девайсу знадобиться набагато менше місця, ніж для звичайних акумуляторів на той самий об’єм енергії
Недоліки:
фактично, він тут один – це ціна, інших поки не побачив
ще до недоліків можна додати, що ані станція, ані мобільний застосунок не попереджають про низький заряд батареї – станція просто мовчки виключається
Щодо шумності: EcoFlow DELTA Max доволі шумна, і включає кулери як під час зарядки, так і під час використання. Спати з такою станцією в одній кімнаті буде не дуже зручно (навряд чи можливо взагалі), тож у випадку однокімнатної квартири-студії треба або вимикати станцію на ніч, або ставити десь в кладовку чи на балкон, а враховуючи відносну пожежобезпечність такого приладу – цілком собі варіант тримати десь там.
Але слідкуйте за температурою, особливо якщо балкон на сонячній стороні, бо в мене станція іноді нагрівається до +45, і починає видавати попередження – доводиться ставити вентилятор. Або закривайте вікна балкона, наприклад Сонцезахисною плівкою.
Мобільний додаток для EcoFlow виглядає ось так – тут підключений ігровий ПК, монітор, роутер, колонки:
Налаштування девайсу:
І під час зарядки – 2000 ват (це на початку, потім зменшується сила струма на батареї, і, відповідно, споживана потужність):
EcoFlow: рекомендації з використання
Кілька рекомендацій по використанню EcoFlow, хоча це відноситься і до інших аналогічних девайсів.
Треба мати на увазі, що деградація батарей – це зменшення їх ємності. 800 циклів в документації EcoFlow – це зменшення ємності до 80% від початкової, а не повністю вихід з ладу. До того ж зараз наче можна легко замінити батареї на нові.
Мінімальний та максимальний рівень заряду
Має сенс виставити обмеження на мінімальний та максимальний рівень заряду – 20% мінімум, і 90% максимум. В такому випадку станція не буде повністю висаджувати батареї, що для них не є ОК, і не буде повністю їх заряджати. Хоча я впевнений, що контролер самої станції і так має потрібні обмеження – але зайвим не буде.
Не тримати постійно на зарядці
Друге, що я роблю – це не тримаю її на зарядці постійно, бо по документації вона розрахована на 800 циклів заряду/розряду (це при Li-ion батареях, для LiFePo4 це здається 3000 циклів). Так – доводиться робити додаткові рухи руками, і перемикати розетки/подовжувачі, коли вимикають/вмикають світло – зато проживе станція довше, бо світло вимикається кілька раз на добу, і кілька раз на добу вмикається зарядка батарей.
Хоча просто тримати її ввімкненою зручно, бо станція вміє працювати як UPS, тобто коли в мережі є енергія – станція живить прилади від мережі, а як в мережі пропадає – то переключається на батареї.
Не перенавантажувати станцію
Ну і, звісно, не можна перенавантажувати станцію. В неї заявлена видача у 2000 ват, є режим X Boost до 4600 ват. Тож не варто підключати стиральну машинку, кавоварку і чайник одночасно.
Вимикати інвертор
Також майте на увазі, що вбудований інвертор станції (взагалі будь-який інвертор) також споживає енергію, навіть якщо не підключено ніяких приладів, і споживає близько 20-30 ват на годину – тобто він з’їсть ~500 ват запасу за добу, навіть працюючи вхолосту. Тому можете або вимикати AC вручну, або налаштувати автовимкнення (дефолт – 12 годин).
Наприклад, з включеним AC при заряді в 34% станція видає 1 день роботи (без приладів):
А з відключеним – 99 годин:
Зменшувати швидкість зарядки
Можна зменшити максимальне навантаження станції під час зарядки батарей (2000 ват/годину в моїй).
Аби включити опцію власного налаштування – на задній панелі треба переключити Fast – Slow/Custom:
Після чого в мобільному застосунку стане доступним налаштування AC charge speed:
Це зменшить струм заряду, і батареї будуть почуватись краще.
Саморобні зарядні станції від “умільців”
Я не скажу, що рекомендував би такий варіант, бо тут занадто багато “як пощастить”: як пощастить з руками майстра, як пощастить з компонентами (Китай/не Китай і т.д.).
Але в цілому – варіант робочий, і в мене одне таке чудо є:
Заявлені такі ж самі 2000 Вт/годин, але реально вдається накопичити близько 1300 – тестував як раз на ігровому ПК, який споживає ~300 ват, і працює близько 4 годин.
В середині це чудо виглядає так:
Синя плата справа – це BMS, Battery Management System, яка контролює заряд акумуляторних батарей – рівень їх заряду/розряду, і додатково може вміти в захист від замикань, перенавантаження тощо.
Переваги:
швидкість зарядки: зазвичай такі станції роблять з потужними зарядками, наприклад в мене вона заряджається за пару годин
компактність: конкретно ця більша за EcoFlow, але це все ще менше місця, ніж 2 акумулятори і ДБЖ, плюс тут все в одному корпусі
ціна: на Olx такі системи продаються за ціною в районі 20.000 грн за 2000 Вт/г, що набагато дешевше, ніж EcoFlow, який, нагадаю, коштує майже 60.000 за 2.000 Вт/г
Недоліки:
надійність: Китай іноді інвертор починає пищати під час роботи, і я поки не зрозумів чому (5 коротких звукових сигналів – хтось, може, в курсі?)
безпека: тут знов-таки покладаємось на руки майстра – наскільки він все правильно зробив (якість пайки, сама схема роботи), наскільки якісні компоненти використовував (а враховуючи факт, що такі станції намагаються зробити не надто дорогими – то можливі нюанси)
шум: під час зарядки гудить, як літак на форсажі – набагато гучніша за EcoFlow
ДБЖ та зовнішні акумулятори
Ще один варіант – це купити окремо акумулятор, і окремо до нього – ДБЖ.
Про типи і ємність акумуляторів теж будемо говорити далі.
Але цей сетап більш резервний, і купувався ще у 2022, коли вибору особливо не було, бо тоді скупали просто все, що з’являлось.
Переваги:
ну, воно працює… в принципі це, мабуть, все
ціна: насправді, не впевнений, чи заносити це в плюси, чи в мінуси, але в порівнянні з EcoFlow цей варіант буде дешевшим (хоча в порівнянні з EcoFlow, мабуть, будь-що буде дешевшим 🙂 )
мені сам ДБЖ обійшовся у 2022 році в 23.000 грн, зараз такий коштує від 16.000 (на Розетці) до тих жеж 23.500 гривень
акумулятор – якщо брати ті ж умовні 2.000 ват/годин (200 ампер/годин на 12 вольт, тобто 1 шт), то за Li-ion це буде близько 20.000 грн, а за LiFePo4 – 35-50 тисяч гривень
надійність: через те, що тут два компоненти, то і говорити про них треба окремо, але щодо самого ДБЖ – то CyberPower наче доволі відома компанія, тож тут можна поставити плюс
безпека: при умовах правильного використання більш безпечне рішення в порівнянні в саморобними станціями, але залежить від самого ДБЖ та акумуляторів, але точно менш безпечне за EcoFlow
Недоліки:
шум: ДБЖ (принаймні цей) доволі шумний під час зарядки, в кімнаті не поставиш (приблизно на рівні EcoFlow)
надійність: а тут вже про акумулятор, і тут багато чого “It depends” – і виробник акумулятору, і те, наскільки ДБЖ правильно заряджає акумулятор(и), і температура в місці, де акумулятор стоїть – бо вони не люблять ані холод, ані жару
безпека: і тут знов-таки дуже багато залежить від акумулятора і умов експлуатації, тому запишу в мінуси, бо ризики вибуху/пожежі акумулятора є
швидкість зарядки: багато залежить від ДБЖ та акумуляторів, але скоріш за все це буде в кілька разів довше (якщо не в 10 раз), ніж той же EcoFlow
компактність: це система, яку треба один раз поставити, і забути, бо з місця на місце просто так не перенесеш – треба розбирати компоненти, і переносити окремо
Окремо зарядне, інвертор та акумулятори
В мене такої системи нема, але в Телеграм-чаті RTFM після публікації першого посту хтось скидав фотки системи вдома, де стоїть акумулятор, окремо до нього підключається зарядне, і окремо – інвертор.
Переваги:
ціна: єдина, мабуть, перевага такого рішення – це ціна, і то не впевнений
Недоліки:
простота: ніякої, бо маєте, по-перше, дуже ретельно вибрати всі компоненти – і акумулятор, і відповідний зарядний пристрій, по-друге – це все з’єднується окремо, і маєте або перемикати постійно вручну – або знов-таки мати мороку з якимись додатковими компонентами контролю/перемикання
безпека: трохи є, але гірше за інші рішення, бо дуже багато “It depends” – як правильно виберете компоненти, надійність компонентів, їхній моніторинг і так далі
компактність: і знов мінус, бо в рішення з ДБЖ+акумулятор у вас принаймні зарядне+інвертор в одному корпусі, а тут – купа проводів
Знайшов фотки з чату в Телеграмі:
І ще окремо сам зарядний пристрій:
Імхо – дуже так собі рішення, бо надто багато геморою.
Втім, на Youtube-каналі @izmailinvertor є багато відео, де людина з прямими руками розказує про такі системи.
Висновки
Тож якщо обирати рішення для дому – то, звісно, якщо є гроші – найкращим варіантом будуть станції по типу EcoFlow.
Другий варіант – це ДБЖ+зовнішні акумулятори. З недоліків – швидкість зарядки і компактність, але має бути дешевшим.
Варіант з саморобними зарядними станціями з Olx особисто я не рекомендував би, бо віри в надійність і безпеку мало. Хоча так – сам вдома таку станцію тримаю, але купував, бо на той час не було грошей, економив, а викинути тепер жалко – “запас карман нє тянєт”.
Ну і варіант “мати все окремо” – це треба бути або дуже шарящою людиною аби все зібрати самому, або мати надійних людей/компанії, які таку систему можуть зібрати для вас. Втім, це все одно доволі геморно з точки зору обслуговування, а я людина лінива.
ДБЖ та інвертори
Мабуть, окремо варто трохи поговорити про різницю між ними, і як їх вибирати.
Отже, ДБЖ – це “all inclusive” система, де в одному корпусі ви маєте і зарядний пристрій для акумуляторів, і інвертор. Зарядний пристрій, власне, заряджає батареї, а інвертор – “розряджає”, тобто передає струм з них на побутові прилади, при потребі збільшуючи струм з 12/24/etc вольт до звичних 220, і перетворюючи його з постійного на змінний.
Інвертор жеж – це тільки перетворення постійного струму 12 вольт з акумулятору на 220 вольт змінного струму, і нічого більше. Хіба що якийсь додатковий захист від замикань/перенавантаження тощо.
І не забуваємо, що будь-який інвертор, навіть в EcoFlow частину енергії витрачає на перетворення струму, приблизно 15%. Тобто, якщо батарея на 1000 ват/годин – то реальної ємності буде 850.
Вибір ДБЖ/інвертора
При виборі ДБЖ є три основних параметри, на які треба звертати увагу – це вихідна та зарядна потужність, і синусоїда.
Вихідна потужність ДБЖ та інверторів
На початку ми порахували, що разом в мене вдома споживається 250 ват/на годину, тож мінімально ДБЖ має бути з запасом хоча б х2, тобто 500 ват – мій CyberPower CPS1000E видає до 700 ват, а EcoFlow – до 2000.
Але тут треба враховувати нюанс з системами типу холодильника, у яких дуже високе споживання при старті двигуна/компресора – від 800 до 1500 ват, тому від CyberPower його захарчувати не вийде, бо або спрацює захист і ДБЖ виключиться – або захист не спрацює, і ДБЖ згорить.
Вольт-ампери та вати
Також потужність ДБЖ часто вказується у вольт-амперах (ВА, також позначається як “повна потужність”), а споживана потужність приладів зазвичай в ватах (“активна потужність”). В такому випадку, аби перевести потужність в вольт-амперах в вати – вольт-ампери множимо на коефіцієнт потужності приладу, зазвичай це 0.6 – 0.9, але має бути вказаний в документації приладу. Можна просто брати середнє значення – 0.85.
Зарядна потужність ДБЖ
І оце дуже важливий момент, про який будемо говорити далі, бо згадуючи зиму 2022/2023, коли світло іноді бувало по кілька годин на добу – то за ці кілька годин вам потрібно повністю зарядити ваші акумулятори.
При цьому є нюанс і з самими акумуляторами, які не дуже люблять високі токи, і якщо якийсь AGM кожен день по кілька раз заряджати на 10 амперах – то спасибі він вам не скаже. Втім, це знов-таки окрема тема, про яку говоритимо далі.
Типи ДБЖ
ДБЖ поділяються на різні типи – в залежності від задачі, для якої проектувались:
резервні ДБЖ (Off-Line, Standby): самі прості, призначені виключно для підстрахування на кілька хвилин – поки світло є, то живлення передається напряму з мережі і паралельно заряджаються акумулятори, а коли вмикається напруга в мережі – то вмикається живлення від акумуляторів
лінійно-інтерактивні (Line-Interactive): поки в мережі є напруга – то передають її на прилади і паралельно згладжують коливання напруги в електромережі, тобто працюють як стабілізатори напруги, при вимиканні світла або перепадах напруги – перемикаються на роботу від батарей
інверторні або ДБЖ безперервної дії (Online): найбільш просунуті системи, які постійно перетворюють струм з мережі в постійний струм, вирівнюють будь-які коливання, перетворюють назад в змінний, а потім передають на прилади
Форма вихідної напруги
ДБЖ можуть видавати чисту або модифіковану синусоїду змінного струму, і деякі прилади вимагають саме чисту – наприклад, двигун холодильника, газовий котел або медична апаратура.
Дуже важлива характеристика ДБЖ, яку треба мати на увазі.
Тему про акумулятори, мабуть, варто було б винести взагалі окремим постом, бо тема досить велика і місцями складна.
Але давайте спробуємо відносно стисло про неї поговорити.
Отже, що ми маємо мати на увазі при виборі акумулятора:
тип: кислотні, AGM, гелеві, LiFePo4 – вибір великий, і важливий
ємність: як правильно розрахувати наскільки вам вистачить акумулятору
швидкість заряду: як вибрати знов-таки тип акумулятору і ДБЖ для нього
Типи акумуляторів
Окрім описаних нижче також є звичайні свинцево-кислотні акумулятори (тягові або стартові – для старту двигуна авто), які також називають автомобільними. Можуть виділяти водень і кисень, а тому пожежонебезпечні, і для дому їх точно використовувати не варто.
Основні характеристики акумуляторів:
кількість циклів заряду-розряду: чим більше виконується циклів перезарядки – тим більше деградує (втрачає ємність батарея)
рівень саморозряду: як швидко акумулятор розряджається без підключених приладів
стійкість до глибокого розряду: наскільки деградує батарея при розряді до мінімальних значень
стійкість до перезаряду:
здатність акумулятора не перегріватися при надмірній зарядці, що впливає на його перегрів і може призвести до займання або вибуху
рівень деградації батареї під час зарядки високим струмом, особливо під час завершення зарядки
температурний режим: допустима/комфортна температура навколишнього середовища
чутливість до зарядного пристрою: різні типи акумуляторів мають різні характеристики процесу заряджання, і ДБЖ має це враховувати
вартість
“ефект пам’яті“: втрата ємності акумулятора при неповному розряді перед наступною зарядкою
швидкість зарядки: власне, як швидко можна зарядити акумулятор – залежить від максимальної сили струму і типу акумулятора
Absorbent Glass Mat (AGM) акумулятори
Також є свинцево-кислотними, але електроліт всередині знаходиться в абсорбованому стані, тому вони герметичні і їх можна встановлювати в будь-яке положення окрім “догори ногами”.
Характеристики:
кількість циклів заряду-розряду: 300-500
рівень саморозряду: низький (1-3% на місяць)
стійкість до глибокого розряду: середня
стійкість до перезаряду: середня
температурний режим: від -20°C до +50°C (оптимально 20-25°C)
чутливість до зарядного пристрою: середня
вартість: середня
“ефект пам’яті“: відсутній
швидкість зарядки: середня (можна заряджати до 20% від ємності на годину)
Переваги:
велика кількість циклів перезаряджання і тривалий термін служби
низький рівень саморозряду
немає “ефекту пам’яті” (можна заряджати у будь-який час, не чекаючи повної розрядки)
швидко заряджаються
Недоліки:
погано переносять перезаряджання (високий струм наприкінці зарядки), тому треба мати відповідний ДБЖ
обмежена кількість циклів заряду-розряду
відносно важкі (бо свинець)
Гелеві та мультигелеві акумулятори
За характеристиками подібні до AGM, але в якості електроліту використовується гель.
Характеристики:
кількість циклів заряду-розряду: 500-800
рівень саморозряду: низький (1-2% на місяць)
стійкість до глибокого розряду: висока
стійкість до перезаряду: висока
температурний режим: від -20°C до +55°C (оптимально 20-25°C)
чутливість до зарядного пристрою: висока
вартість: вище середньої
“ефект пам’яті“: відсутній
швидкість зарядки: низька (можна заряджати 10-15% від ємності на годину)
Переваги:
довго можуть бути розрядженими
пристосовані під циклічний характер роботи з глибоким розрядом
допустимість короткострокових глибоких розрядів
Недоліки:
висока вартість
чутливість до коротких замикань
повільна зарядка
більша чутливість до температур, хоча працюють при температурі від -30 до +50
чутливі до зарядного пристрою
LiFePO4
Нове покоління акумуляторів – літій-залізо-фосфатні. Також герметичні, зокрема використовується в електромобілях.
Характеристики:
кількість циклів заряду-розряду: 2000-5000
рівень саморозряду: дуже низький (менше 1% на місяць)
стійкість до глибокого розряду: дуже висока
стійкість до перезаряду: висока
температурний режим: від -20°C до +60°C (оптимально 15-35°C)
чутливість до зарядного пристрою: висока (потребує спеціального зарядного пристрою або просунутий ДБЖ)
вартість: висока
“ефект пам’яті“: відсутній
швидкість зарядки: дуже висока (можна заряджати до 1C, тобто струм заряду може дорівнювати ємності акумулятора, деякі моделі підтримують ще швидшу зарядку)
Переваги:
велика кількість циклів перезаряджання і тривалий термін служби – набагато більший, ніж у AGM та гелевих акумуляторів
низький рівень саморозряду
широкий діапазон робочих температур (від -15 до +60°C)
не бояться великих струмів (можна швидше заряджати)
висока швидкість заряджання – і за рахунок можливості подачі більш високого струму, ніж у AGM та гелевих акумуляторів, і за рахунок самої технології
Недоліки:
висока вартість в порівнянні з AGM та гелевими акумуляторами
потребують спеціальної системи управління зарядкою
Інші типи літій-іонних акумуляторів
Окрім LiFePO4 є і інші типи літій-іонних акумуляторів:
Li-ion (літій-кобальт оксид, LiCoO2): найпоширеніший тип, використовується в смартфонах, ноутбуках
LiMn2O4 (літій-марганець оксид): використовується в електроінструментах, медичному обладнанні
NMC (літій-нікель-марганець-кобальт): поширений в електромобілях та портативній електроніці
NCA (літій-нікель-кобальт-алюміній): використовується в електромобілях Tesla та деяких портативних пристроях.
Висновки
Свинцево-кислотні AGM: надійні, доступна ціна, хороший вибір для більшості домашніх систем
Гелеві акумулятори: підходять там, де необхідна глибока розрядка і довготривала робота без підзарядки, підходять для систем з частими і довгими відключеннями електроенергії
LiFePO4: все “най-” – найдовший термін служби, найшвидша зарядка, найкраща безпечність
Рекомендації по експлуатації акумуляторів
правильна зарядка:
використовуйте зарядні пристрої, призначені для конкретного типу акумулятора
уникайте перезаряду, особливо для свинцево-кислотних акумуляторів
для літій-іонних акумуляторів підтримуйте рівень заряду між 20% і 80%
температурний режим: зберігайте і експлуатуйте акумулятори в рекомендованому температурному діапазоні, особливо, якщо акумулятори десь на балконі, який влітку нагрівається від сонця
глибина розряду:
для свинцево-кислотних акумуляторів уникайте глибокого розряду (нижче 50%)
LiFePO4 акумулятори краще переносять глибокий розряд, але краще не розряджати нижче 20%
регулярне використання: періодично використовуйте акумулятори, не залишайте їх повністю зарядженими або розрядженими на тривалий час
зберігання: при тривалому зберіганні підтримуйте частковий заряд (40-60%)
Рівень розряду акумулятора та його ємність
Важливий момент, котрий треба враховувати при розрахунках: розряджати акумулятор бажано максимум до 30-40% його ємності, хоча це дуже залежить від типу – гелеві цього не люблять, AGM трохи краще переживає глибокий розряд, а LiFePO4 краще інших.
Давайте порахуємо скільки реальної (або корисної) ємності буде в акумуляторі.
Наприклад, маємо AGM 12 вольт на 100 ампер/годин – отримуємо 1200 ват/годин повної ємності.
Від цих 1200 віднімаємо хоча б 30% заряду, який потрібно залишати, аби батареї в акумуляторі почувались краще – і вже маємо 800 ват/годин.
І додатково від цих 800 Вт/г віднімаємо ще втрати на роботу інвертора – це відсотків 15, і в залишку корисної або реальної ємності вже маємо 680 ват/годин.
За цим треба або слідкувати самому (якщо використовуємо схему з окремим інвертором+зарядне+акумулятор), або сам ДБЖ має відключатись автоматично при низькому заряді батареї (і буде добре, якщо ДБЖ досить інтелектуальний, аби враховувати тип акумулятору).
Зарядка акумуляторів та важливість вибору правильного ДБЖ
Отже, від того, який саме у вас тип акумулятора дуже сильно залежить те, як він має заряджатись.
Ще один важливий нюанс при виборі акумулятору та ДБЖ – це скільки часу буде займати зарядка.
Час заряду залежить від:
типу акумулятора: різні типи мають різний рівень швидкості зарядки, і у LiFePo4 найшвидша зарядка
максимальний/рекомендований струм заряду:
свинцево-кислотні AGM, мультигель та гель мають рекомендований рівень в 0.1С (1/10 ємності), тобто акумулятор в 100 ампер-годин можна заряджати максимум на 10 амперах, в такому випадку повний цикл зарядки займе 10 годин
LiFePo4 можна заряджати на струмі 0.5С – 1С, тобто акумулятор на 100 ампер-годин можна заряджати струмом від 50 ампер, і повний цикл зарядки займе 2 години
При перевищені струму заряду батарея може перегрітись і вибухнути (проте вас покажуть по телевізору).
На струм заряду може впливати вбудована плата BMS, про яку згадував вище, бо вона може мати власні обмеження. Втім, не варто покладатись тільки на неї (тим більш, її може і не бути), а читати документацію до ДБЖ та акумулятора.
При такому підключенні всі плюси та всі мінуси батарей підключаються до плюса на ДБЖ. В такому випадку загальна ємність сумується, але напруга лишається такою ж самою:
Тобто, отримаємо 200 ампер/годин і 12 вольт.
Дозволяє використовувати акумулятори з різною ємністю, але може призвести до нерівномірного розряду акумуляторів.
Послідовне підключення
Позначається на акумуляторах як S (serial).
При такому підключенні мінус одного акумулятора підключається до плюса наступного. В результаті ємність залишається такою ж самою, але їхня напруга сумується:
Тобто, отримаємо 100 ампер/годин і 24 вольт.
Вимагає точного підбору акумуляторів за ємністю та станом.
12 вольт vs 24 вольти: а для чого?
Схема підключення залежить від того, який ДБЖ у вас використовується, бо ДБЖ на 12 вольт не видасть високої потужності. 1000-2000 ват потужності для таких ДБЖ, мабуть, максимум.
Наприклад, у нас є кавоварка, яка працює з напругою 220 вольт і споживає 1000 ват/годин. Маємо інвертор, до якого підключено акумулятор на 12 вольт.
В такому випадку аби забезпечити необхідну потужність у 1000 ват від інвертора до кавоварки нам потрібна сила струму у 1000W/220V=4.54 ампери. Але сила струму від акумулятора до інвертора вже буде 1000W/12V, тобто 83 ампери. Відповідно, великі втрати на передачу енергії, і потрібні більш товсті кабелі. А при використанні інвертора на 24 вольти – це було б 41.6 ампери.
Це дуже грубий приклад, але основна ідея така.
То що в результаті? І трохи про розетки.
Отже, якщо повернутись до початку цього посту:
у нас є 4500 ват-годин на добу споживання
ми хочемо зарядити акумулятори за умовні 2 години
Чому 2 години? Бо, по-перше, говорять, що цією зимою в найгіршому варіанті світло буде 4 години на добу, але давайте ми будемо песимістами х2, і припускати, що світло буде лише 2 години на добу.
По-друге – EcoFlow свої 2 кіловат/години заряджає менш ніж за 2 години, і хочеться побудувати щось хоча б приблизно таке ж саме.
Що ми можемо зробити, аби забезпечити себе хоча б на добу?
Варіант 1 – купити пару EcoFlow. Дорого, але надійно.
Варіант 2 – купувати ДБЖ та акумулятори. З урахування специфіки різних типів АКБ, якщо ми хочемо заряджати швидко – то нам потрібні LiFePo4.
4500 ват-годин запасу – це 375 ампер/годин при 12 вольтах – тобто, 2 акуми по 200 ампер-годин. І це якщо рахувати тільки повну ємність – без втрат на перетворення і “залишковий запас” акумулятора, аби не розряджати його повністю.
А аби їх зарядити за 2 години – нам потрібен ДБЖ/зарядне, яке буде видавати 100 ампер! І таке зарядне потрібне на кожен акумулятор окремо!
Таке, звісно, реалізувати можна, але я не зустрічав таких зарядних пристроїв. До того ж, аби витримати таку силу струму будуть потрібні ну прям дуже товсті кабелі.
Тому єдине, що можна зробити – це підключити акумулятори послідовно, аби мати напругу у 24 вольти (в EcoFlow, наприклад, батареї працюють на 48 вольтах – як раз для того, аби знизити необхідну силу струму).
А маючи 24 вольти – ми можемо заряджати їх при струмі в 50 ампер, що вже більш реально, і такі зарядні пристрої знайти можна.
Тоді будемо мати 50 ампер * 24 вольти == 1200 ват потужності, а повна зарядка акумуляторів займе ~4 години. А насправді навіть більше, бо насправді “профіль зарядки” виглядає не рівномірно. Див. ось цей момент у відео – там людина малює графіки заряду.
В такому випадку, якщо ми беремо собі ліміт в 50 ампер – то варіанти будуть такі:
зарядне на 50 ампер + 2 акумулятори по 200 А/г послідовно: отримуємо ~2000 ват/годин, зарядка 4 години
зарядне на 50 ампер + 2 акумулятори по 100 А/г послідовно: отримуємо ~1000 ват/годин, зарядка 2 години
І аби забезпечити свої 4500 ват/годин запасу на добу, нам потрібно або два комплекти з двома акумуляторами по 200 А/г – які будуть заряджатись 4 години, або 4 комплекти з двома акумуляторами по 100 А/г – які будуть заряджатись за 2 дві години.
Але навіть якщо ми підемо на зборку 4-х комплектів – нам їх потрібно заряджати одночасно!
А маючи 1200 ват потужності через розетку на зарядку одного такого блоку батарей в розетці будемо мати 1200/220 = 5.4 ампер, що в принципі нормально, бо стандартно розетки розраховані на 16 ампер максимум – і це треба мати на увазі.
Тобто в одну розетку ми можемо максимум одночасно включити 2 комплекти – сила струму через розетку буде близько 10 ампер.
А включати одночасно 2 EcoFlow в один блок розеток або навіть в одній кімнаті все ж не варто: один EcoFlow при зарядці споживає до 2000 ват, тобто 9 ампер з розетки, до якої від підключений.
Це грубі розрахунки, але плюс-мінус виходить так.
Підсумки і варіанти
А тепер давайте порахуємо вартість варіантів на ~2000 Вт/годину (але пам’ятаємо, що ми нарахували необхідний добовий запас в 4500 Вт/г).
Строк служби далі – доволі умовна одиниця, бо батарея не вмре повністю, а просто втратить частину своєї ємності.
EcoFlow на 2000 Вт/годин з Li-ion батареями
Найкращій варіант з усіх точок зору, окрім ціни:
ціна: ~60.000 гривень
строк служби: враховуючи заявлені 800 циклів заряду, при щоденних відключеннях електрики пропрацює ~2-3 роки
плюси:
просто працює
компактні, можна перенести
швидко заряджається
мінуси: ціна
Якщо ж брати відразу з LiFePo4 батареями (нагадаю – близько 100.000 гривень на сьогодні) – то це гарантовано років 5 і більше роботи.
Або за 105.000 взагалі відразу взяти EcoFlow DELTA Pro на 3600 Вт/годин з тими ж LiFePo4.
Ну і не EcoFlow єдиним – подібних рішень багато. Просто в мене вона є, тому пишу про неї.
ДБЖ з зовнішнім LiFePo4 акумулятором на 200 ампер/годин (~2000 Вт/годин)
Непоганий варіант, але не транспортабельний і за ціною може вийти не набагато дешевше за EcoFlow. Втім, прослужить скоріш за все довше за EcoFlow з Li-ion:
ціна:
ДБЖ: 10-15 тисяч гривень
акумулятор: від 35 до 50 тисяч
строк служби: враховуючи ~3000 циклів заряду, при щоденних відключеннях електрики – пропрацює ~4-5 років
плюси:
трохи дешевший за EcoFlow
при правильно підібраному зарядному пристрої – швидко заряджається
достатньо надійно і безпечно
мінуси:
швидкість заряду: залежить від зарядного, але навряд чи вам вдасться “залити” його повністю за 2-3 години, навіть використовуючи LiFePo4 (або брати менші за ємністю акумулятори в більшій кількості – а це вплине на загальну вартість системи)
не можна просто так перенести в інше приміщення
потребує додаткових знань, додаткового обслуговування, моніторингу, обережності
Можна замість LiFePo4 взяти AGM-акумулятори – вийде в пару раз дешевше, але вони і заряджатись будуть в кілька раз довше, і строк служби буде в кілька раз меншим.
Найбільш небезпечний, проте самий бюджетний варіант:
ціна: від 20-25 тисяч гривень
строк служби: на 1-2 роки можна розраховувати, але навряд чи більше (скоріш менше, і тут вже саме про те, скілька така станція пропрацює взагалі, а не втрата ємності батареї)
плюси:
компактні, можна перенести
швидко заряджається
мінуси:
надійність – може зламатись в будь-який момент
безпека і пожежонебезпечність: відносно до EcoFlow або ДБЖ з LiFePo4 акумулятором доволі (дуже?) небезпечне рішення
шумні
В цілому, це, мабуть, все.
І капелька про павербанки
Ну і павербанки ніхто не відміняв.
Це мій запас, який зробив ще в кінці минулого року:
Тут:
дві зарядні станції Kseni по 160.000 mAh (до них інвертор на 500 ват)
два павербанка FutureSolar по 160.000 mAh (до них два інвертори на 150 ват кожен – телевізор від них працює без проблем)
один павербанк ChinaNoName на 60.000 mAh
два павербанка ChinaNoName по 50.000 mAh
два павербанка Baseus по 30.000 mAh
два павербанка Xiomi по 20.000 mAh
Живити через інвертор від павербанок всякі ноутбуки/монітори/світильники можна спокійно, а от холодильник і котел – вже тільки від ДБЖ/EcoFlow. Втім тут ще пам’ятаємо, що сам інвертор буде з’їдати частину енергії (хоча ноутбук можна напряму, якщо потужність павербанка дозволяє).
Як рахувати ємність павербанка?
Тут вже зовсім коротенько.
Ємність на всіх банках вказується з розрахунком на 3.7 вольти, але по факту на виході більшість видає 5 вольт. Якщо через автомобільний “прикурювач” – то там 12 вольт:
Формула:
мА/г * Вольти / 1000
Тепер рахуємо:
павербанк з 60.000 номінальної ємності при 3.7 вольти – це 60.000 (міліампер/годин) * 3.7 вольти == 222 ват-години
той же павербанк при 5 вольтах на виході – це вже 222 (ват-години) / 5 (вольт) == 44.400 mAh
а він жеж, живлячи інвертор на 12 вольтах – 18.500 mAh
Готуємось мігрувати базу даних нашого Backend API з DynamoDB до AWS RDS з PostgreSQL, і нарешті вирішив спробувати що ж таке AWS RDS IAM database authentication, який з’явився здається ще десь у 2021.
IAM database authentication, як, в принципі, можна здогадатись з назви, дозволяє нам виконувати аутентифікацію в RDS за допомогою AWS IAM, а не логіна-пароля з самого сервера баз даних.
Втім, авторизація – тобто перевірка які саме доступи є у юзера в базі/базах, залишаються за самим сервером БД, бо IAM нам тільки дасть доступ до самого інстансу RDS.
Тож що будемо робити:
спочатку руками спробуємо як працює RDS IAM database authentication, і як вона конфігуриться
потім перейдемо до автоматизації з Terraform, і заодно поглянемо на те, як працює AWS EKS Pod Identities
напишемо код на Python, який буде запускатись в Kubernetes Pod з SericeAccount та підключатись до RDS використовуючи RDS IAM database authentication
поговоримо про проблеми при використанні RDS IAM database authentication та автоматизації з Terraform
Тестую на RDS, який створюється для Grafana, тому подекуди будуть імена з “monitoring“/”grafana“.
Загальна ідея – замість паролю до RDS використовується IAM-токен для IAM Role або IAM User, до яких підключено IAM Policy, яка описує ID Aurora-кластеру або RDS-інстансу та ім’я користувача.
Але, нажаль, на цьому роль IAM завершується, бо доступи та права в самому сервері баз даних створюються і керуються як і раніше, тобто через CREATE USER та GRANT PERMISSIONS.
IAM database authentication та Kubernetes ServiceAccount
Відносно Kubernetes Pod я, чесно кажучи, очікував трохи більшого, бо мені здавалось, що просто використовуючи IAM Role та Kubernetes ServiceAccount можна буде взагалі без паролю підключатись до RDS – як ми це робимо з доступом до інших ресурсів в AWS через AWS API.
Але з RDS схема виглядає трохи інакше:
створюємо інстанс RDS з параметром IAM authentication == true
створюємо IAM Role з IAM Policy
в PostgreSQL/MariaDB створюємо відповідного користувача, включаємо йому аутентифікацію через IAM
в Kubernetes створюємо ServiceAccount з цією роллю
підключаємо цей ServiceAccount до Kubernetes Pod
в Pod, використовуючи IAM Role з ServiceAccount, генеруємо IAM RDS Token для доступу для RDS
і вже з цим токеном підключаємось до серверу RDS
Давайте спочатку спробуємо руками, а потім глянемо, як це зробити з Terraform – бо там є свої нюанси.
RDS IAM authentication: перевірка
Отже, маємо вже створений RDS PostgreSQL з Password and IAM database authentication:
Для серверу вже маємо дефолтного master-юзера та пароль в SecretsManager – він знадобиться для додавання нового користувача.
Знаходимо ID інстансу – буде потрібен в IAM Policy:
Створення IAM Policy
Далі нам потрібна IAM Policy, яка буде дозволяти доступ юзеру до цього інстансу RDS.
Тут ми Allow виконати дію rds-db:connect до сервера бази даних в Resource використовуючи ім’я користувача db_test, і цього ж користувача db_test ми потім додамо з CREATE USER на самому сервері БД.
Зверніть увагу, що інстанс RDS вказується не як його ім’я – а саме як його ID – db-XXXYYYZZZ.
Зберігаємо політику:
Політику можемо підключити напряму до свого юзера AWS, або використати IAM Role.
З роллю спробуємо пізніше, коли будемо підключати Kubernetes Pod, а зараз для перевірки схеми в цілому давайте використаємо звичайного IAM User.
Знаходимо необхідного IAM User та додаємо пермішени:
Вибираємо Attach policies directly, знаходимо нашу IAM Policy:
$ psql "host=$RDSHOST sslmode=require dbname=ops_grafana_db user=db_test password=$PGPASSWORD"
psql: error: connection to server at "ops-monitoring-rds.***.us-east-1.rds.amazonaws.com" (10.0.66.79), port 5432 failed: FATAL: PAM authentication failed for user "db_test"
FATAL: PAM authentication failed for user “db_test”
В моєму випадку помилка виникла, бо я спершу генерив токен з “--region us-west-2“, а сервер знаходиться в us-east-1 (привіт, copy-paste з документації 🙂 ).
Тобто помилка виникає саме через помилки в налаштуваннях доступу – або в IAM Policy вказано інший username, або при CREATE USER вказано інше ім’я, або токен згенеровано для іншої IAM-ролі.
Перегенеримо токен, пробуємо ще раз:
$ psql "host=$RDSHOST sslmode=require dbname=ops_grafana_db user=db_test password=$PGPASSWORD"
psql (16.2, server 16.3)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.
ops_grafana_db=>
ops_grafana_db=> \dt
List of relations
Schema | Name | Type | Owner
--------+-----------------------------+-------+------------------
public | alert | table | ops_grafana_user
public | alert_configuration | table | ops_grafana_user
public | alert_configuration_history | table | ops_grafana_user
...
При чому password=$PGPASSWORD можна не вказувати – psql сам зчитає змінну PGPASSWORD, див. Environment Variables.
dbname=ops_grafana_db тут – бо сервер створюється для Grafana, і це її база.
Окей – це перевірили, працює.
Тепер час Kubernetes та автоматизації з Terraform – і тут наші пригоди тільки починаються.
Terraform та AWS EKS Pod Identity з IAM database authentication
Давайте глянемо, як ця схема буде працювати з Kubernetes Pod та ServiceAccount.
в Trusted Policy цієї IAM Role будемо мати pods.eks.amazonaws.com
роль додамо до кластеру через EKS IAM API
створимо Kubernetes Pod та ServiceAccount
в поді запустимо код на Python, який буде підключатись до RDS
Тобто, Kubernetes Pod для аутентифікації в AWS API буде використовувати IAM Role з Kubernetes ServiceAccount, потім, використовуючи цю роль, від AWS API отримає AWS RDS Token, і вже з цим токеном підключиться до RDS.
Створення AWS EKS Pod Identity з Terraform
Для AWS EKS Pod Identity є модуль eks-pod-identity, візьмемо його.
В Terraform описуємо aws_iam_policy_document з доступом до RDS:
Policy нова, і юзера використаємо теж нового – test_user.
В ${data.aws_caller_identity.current.account_id} ми маємо AWS Account ID:
data "aws_caller_identity" "current" {}
В ${module.monitoring_rds.db_instance_resource_id} – ID нашого RDS-інстансу, який створюється за допомогою модулю terraform-aws-modules/rds/aws з параметром iam_database_authentication_enabled:
module "monitoring_rds" {
source = "terraform-aws-modules/rds/aws"
version = "~> 6.7.0"
identifier = "${var.environment}-monitoring-rds"
...
# DBName must begin with a letter and contain only alphanumeric characters
db_name = "${var.environment}_grafana_db"
username = "${var.environment}_grafana_user"
port = 5432
manage_master_user_password = true
manage_master_user_password_rotation = false
iam_database_authentication_enabled = true
...
}
Далі з terraform-aws-modules/eks-pod-identity/aws описуємо EKS Pod Identity Association, де використовуємо aws_iam_policy_document.monitoring_rds_policy, який зробили вище:
# get info about a cluster
data "aws_eks_cluster" "eks" {
name = local.eks_name
}
Деплоїмо, і перевіряємо IAM:
Та Pod Identity associations в AWS EKS:
Тепер маємо IAM Role, до якої підключена IAM Policy, яка надає доступ юзеру test_user до RDS-інстансу з ID db-UZM***3SA, та маємо встановлений зв’язок між ServiceAccount з іменем eks-test-sa в Kubernetes-кластері та цією IAM-роллю.
Python, PostgreSQL та IAM database authentication
Що має відбуватись далі:
створимо Kubernetes Pod
створимо ServiceAccount з іменем eks-test-sa
напишемо код на Python, який буде:
використовуючи ServiceAccount та пов’язану з ним IAM Role підключатись до AWS API
отримає AWS RDS Token
з цим токеном підключиться до RDS
Знов заходимо на RDS з мастер-юзером, і створюємо нового користувача test_user (як вказано в IAM Policy) з роллю rds_iam:
ops_grafana_db=> CREATE USER test_user;
CREATE ROLE
ops_grafana_db=> GRANT rds_iam TO test_user;
GRANT ROLE
ops_grafana_db=> GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO test_user;
GRANT
Описуємо ServiceAccount eks-test-sa та Kubernetes Pod з цим ServiceAccount в namespace=ops-monitoring-ns:
$ kk apply -f eks-test-rds-irsa.yaml
serviceaccount/eks-test-sa created
pod/eks-test-pod created
Підключаємось в под:
$ kk exec -ti eks-test-pod -- bash
root@eks-test-pod:/#
Встановлюємо python-boto3 для отримання токену та python3-psycopg2 для роботи з PostgreSQL:
root@eks-test-pod:/# apt update && apt -y install vim python3-boto3
Пишемо код:
#!/usr/bin/python3
import boto3
import psycopg2
DB_HOST="ops-monitoring-rds.***.us-east-1.rds.amazonaws.com"
DB_USER="test_user"
DB_REGION="us-east-1"
DB_NAME="ops_grafana_db"
client = boto3.client('rds')
# using Kubernetes Pod ServiceAccount's IAM Role generate another AWS IAM Token to access RDS
db_token = client.generate_db_auth_token(DBHostname=DB_HOST, Port=5432, DBUsername=DB_USER, Region=DB_REGION)
# connect to RDS using the token as a password
conn = psycopg2.connect(database=DB_NAME,
host=DB_HOST,
user=DB_USER,
password=db_token,
port="5432")
cursor = conn.cursor()
cursor.execute("SELECT * FROM dashboard_provisioning")
print(cursor.fetchone())
conn.close()
В принципі він досить простий – підключаємось до AWS, отримуємо токен, підключаємось до RDS.
ServiceAccount через Pod Identity associations пов’язаний з IAM Role ops-monitoring-rds-role
IAM Role ops-monitoring-rds-role має IAM Policy з Allow на rds-db:connect
Kubernetes Pod використовує IAM Role з ServiceAccount для аутентифікації та авторизації в AWS
після чого в Python з boto3 та client.generate_db_auth_token отримує RDS Token
і використовує його для підключення для PostgreSQL
На самому RDS ми вже маємо створеного юзера test_user з rds_iam та доступом до баз даних.
Про те, як саме працює Kubernetes ServiceAccounts та токени на рівні Kubernetes Pod див. в AWS: EKS, OpenID Connect та ServiceAccounts (тільки там описано ще без Pod Identity associations, але механізм той самий).
Виглядає, як робочий варіант – але залишився ще один нюанс.
Terraform та IAM RDS Authentication: складнощі
Вся наша схема з Terraform наче робоча – але ми руками створювали test_user та давали йому пермішени.
І тут ще один недолік схеми RDS та IAM database authentication – бо нам все одно потрібно створювати юзера в сервері БД.
А звідси випливає ще одна проблема – як це робити з Terraform?
Я не став вже витрачати на це час, бо нам в принципі це не дуже актуально, бо буде лише кілька юзерів і їх можна зробити руками, а поточну автоматизацію це не блокує.
Але з часом, коли проект виросте, то це питання все одно доведеться вирішувати.
Отже, які проблеми і варіанти вирішення маємо:
ми можемо створити PostgreSQL (чи MariaDB) юзерів прямо з коду Terraform використовуючи PostgreSQL provider, і виконавши local-exec або використавши resource "postgresql_grant"
але для цього потрібен доступ до самого RDS, який знаходиться в приватній мережі VPC, а тому для CI/CD потрібен мережевий доступ до VPC, що, в принципі, можливо, якщо запускати GitHub Runners (в нашому випадку) в Kubernetes, чиї WorkerNodes мають доступ до приватних сабнетів – але зараз ми використовуємо Runners самого GitHub, і у них цього доступу нема
другий варіант – використовувати AWS Lambda, яка буде запускатись в VPC з доступом до RDS, і створювати юзерів
виглядає цілком робочим варіантом, крім того замість AWS Lambda ми можемо з Terraform описати запуск Kubernetes Pod, який буде виконувати необхідні дії – підключення до RDS та CREATE USER
Обидів схеми цілком робочі, і колись, можливо, опишу реалізацію одного з них (скоріш за все другого).
Але на даний момент не бачу сенсу витрачати на це час.
Висновки
А висновки насправді трохи неоднозначні.
Сама ідея з RDS IAM database authentication виглядає дуже цікаво, але той факт, що токен для RDS і звичайний токен аутентифікації в AWS API для IAM Role являють собою різні сутності трохи ускладнює реалізацію, бо якби до RDS можна було конектитись просто використовуючи ServiceAccount та IAM Role – це дуже спростило б використання.
Крім того, чомусь очікував, що й авторизація буде робитись на рівні IAM – тобто, прямо в IAM Policy можна буде вказати хоча б бази даних, до яких будуть доступи. Але це залишається на рівні сервера БД.
Друга проблема полягає в тому, що нам все одно доводиться створювати юзера в RDS і видавати йому права, що знов-таки створює додаткові складнощі в автоматизації.
Втім, в цілому свою задачу RDS IAM database authentication виконує – нам дійсно не потрібно створювати якийсь Kubernetes Secret з паролем для бази даних і маунтити його до Kubernetes Pod, а достатньо підключити ServiceAccount, а отримання токену ми вже “перекладаємо на плечі девелоперів” – тобто виконуємо на рівні коду, а не Kubernetes.
І, думаю, ми все ж будемо цей механізм використовувати у нас в Production.
Маємо API-сервіс в Kubernetes, який періодично видає 502, 503, 504 помилки.
Почав його дебажити, і виявив дивну штуку – в логах не було повідомлень про отриманий SIGTERM, а тому спочатку пішов розбиратись з Kubernetes – чому він його не відправляє?
The Issue
Отже, як це виглядає.
Маємо Kubernetes Pod:
$ kk get pod
NAME READY STATUS RESTARTS AGE
fastapi-app-89d8c77bc-8qwl7 1/1 Running 0 38m
Читаємо його логи:
$ ktail fastapi-app-59554cddc5-lgj42
==> Attached to container [fastapi-app-59554cddc5-lgj42:fastapi-app]
Вбиваємо його:
$ kk delete pod -l app=fastapi-app
pod "fastapi-app-6cb6b46c4b-pffs2" deleted
І бачимо, що у нас тут PID 1 – це процес /bin/sh, який через -c запускає gunicorn.
Тепер давайте в поді запустимо strace, і подивимось які сигнали він отримує:
root@fastapi-app-6cb6b46c4b-9pd7r:/app# strace -p 1
strace: Process 1 attached
wait4(-1,
Виконуємо kubect delete pod – але додамо time, аби заміряти час на виконання команди:
$ time kk delete pod fastapi-app-6cb6b46c4b-9pd7r
pod "fastapi-app-6cb6b46c4b-9pd7r" deleted
real 0m32.222s
32 секунди…
А що в strace?
root@fastapi-app-6cb6b46c4b-9pd7r:/app# strace -p 1
strace: Process 1 attached
wait4(-1, 0x7ffe7a390a3c, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=0, si_uid=0} ---
wait4(-1, <unfinished ...>) = ?
command terminated with exit code 137
Отже, що тут відбувалось:
kubelet відправив сигнал SIGTERM процесу з PID 1 – SIGTERM {si_signo=SIGTERM} – і PID 1 мав би передати цей процес своїм дочірнім процесам, зупинити їх, а потім завершитись сам
але процес не завершився – і kubelet почекав дефолтні 30 секунд, аби под коректно завершив свою роботу – див. Pod phase
після чого вбив контейнер, і процес завершився з “terminated with exit code 137“
Зазвичай код 137 – це про OutOfMemory Killer, коли процес вбивається з SIGKILL, але в нашому випадку OOMKill не було – а просто відбувся SIGKILL через те, що процеси в поді не завершились вчасно.
Добре – а куди подівся наш SIGTERM?
Давайте виконаємо сигнали напряму з контейнеру – спочатку kill -s 15, SIGTERM, потім kill -s 9, SIGKILL:
root@fastapi-app-6cb6b46c4b-r9fnq:/app# kill -s 15 1
root@fastapi-app-6cb6b46c4b-r9fnq:/app# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 2576 920 ? Ss 12:02 0:00 /bin/sh -c gunicorn -w 1 -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:80 app:app
root 7 0.0 1.4 31852 27644 ? S 12:02 0:00 /usr/local/bin/python /usr/local/bin/gunicorn -w 1 -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:80 app:app
...
root@fastapi-app-6cb6b46c4b-r9fnq:/app# kill -s 9 1
root@fastapi-app-6cb6b46c4b-r9fnq:/app# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 2576 920 ? Ss 12:02 0:00 /bin/sh -c gunicorn -w 1 -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:80 app:app
root 7 0.0 1.4 31852 27644 ? S 12:02 0:00 /usr/local/bin/python /usr/local/bin/gunicorn -w 1 -k uvicorn.workers.UvicornWorker --bind 0.0.0.0:80 app:app
Шо? Як?
Чому ігнорується SIGTERM? А тим більш SIGKILL, який має бути “non ignorant signal” – див. man signal:
The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
Linux kill() та PID 1
Бо PID 1 в Linux є особливим процесом, бо це перший процес, який запускається системою, і він має бути “захищений” від “випадкового вбивства”.
Якщо ми глянемо на man kill, то там це явно вказано, а також сказано про хендлери сигналів до процесу:
The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed signal handlers. This is done to assure the system is not brought down accidentally
Перевірити які хендлери є у нашого процесу – тобто, які сигнали наш процес може перехопити і обробити – можна з файлу /proc/1/status:
SigCgt – це сигнали, які процес може перехопити і обробити сам. Решта будуть або проігноровані, або опрацьовані з SIG_DFL handler, а SIG_DFL handler ігнорує сигнали для PID 1, у якого нема власного хендлера.
перевірка PID 1 вказує нам, що він “розпізнає” тільки сигнали SIGHUP і SIGCHLD
SIGTERM та SIGKILL будуть ним проігноровані
Але як жеж тоді зупиняється контейнер?
Docker stop та сигнали
Процес зупинки контейнера в Docker (або Containerd) не відрізняється від того, як це в Kubernetes, бо по факту kubelet просто передає команди на container runtime. В AWS Kubernetes це зараз containerd.
Але задля простоти давайте виконаємо це локально з Docker.
Отже, запускаємо контейнер з того самого образу, який тестили в Kubernetes:
$ docker run --name test-app 492***148.dkr.ecr.us-east-1.amazonaws.com/fastapi-app-test:entry-2
[2024-06-22 14:15:03 +0000] [7] [INFO] Starting gunicorn 22.0.0
[2024-06-22 14:15:03 +0000] [7] [INFO] Listening at: http://0.0.0.0:80 (7)
[2024-06-22 14:15:03 +0000] [7] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2024-06-22 14:15:03 +0000] [8] [INFO] Booting worker with pid: 8
[2024-06-22 14:15:03 +0000] [8] [INFO] Started server process [8]
[2024-06-22 14:15:03 +0000] [8] [INFO] Waiting for application startup.
[2024-06-22 14:15:03 +0000] [8] [INFO] Application startup complete.
Пробуємо його зупинити через відправку SIGKILL до PID 1 – нічого не змінилося, він ігнорує сигнал:
$ docker exec -ti test-app sh -c "kill -9 1"
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
99bae6d55be2 492***148.dkr.ecr.us-east-1.amazonaws.com/fastapi-app-test:entry-2 "/bin/sh -c 'gunicor…" About a minute ago Up About a minute test-app
Пробуємо зупинити з docker stop – і знов дивимось на час:
$ time docker stop test-app
test-app
real 0m10.234s
І статус контейнера:
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
cab29916f6ba 492***148.dkr.ecr.us-east-1.amazonaws.com/fastapi-app-test:entry-2 "/bin/sh -c 'gunicor…" About a minute ago Exited (137) 52 seconds ago
Той жеж код 137, тобто контейнер зупинився з SIGKILL.
Але як, якщо сигнал відправляється до PID 1, котрий його ігнорує?
Я не знайшов цього в документації до docker kill, але ми можемо вбити процеси контейнеру двома шляхами:
вбити всі дочірні процеси в самому контейнері – і тоді parent (PID 1) вмре сам
вбити всю групу процесів на хості через їхній SID (Session ID) – що знову-таки призведе до того, що PID 1 проігнорує сигнал, але вмре сам, бо померли всі його дочірні процеси
Вбити PID 1 ми не можемо, бо він нас ігнорує – але ми можемо вбити PID 7!
Тоді він за собою вб’є PID 8, бо це його дочірній процес, а коли PID 1 виявить, що більше нема його дочірніх процесів – то він вмре сам, і контейнер зупиниться:
root@cddcaa561e1d:/app# kill 7
І логи контейнеру:
...
[2024-06-22 16:02:54 +0000] [7] [INFO] Handling signal: term
[2024-06-22 16:02:54 +0000] [8] [INFO] Shutting down
[2024-06-22 16:02:54 +0000] [8] [INFO] Error while closing socket [Errno 9] Bad file descriptor
[2024-06-22 16:02:54 +0000] [8] [INFO] Waiting for application shutdown.
[2024-06-22 16:02:54 +0000] [8] [INFO] Application shutdown complete.
[2024-06-22 16:02:54 +0000] [8] [INFO] Finished server process [8]
[2024-06-22 16:02:54 +0000] [7] [ERROR] Worker (pid:8) was sent SIGTERM!
[2024-06-22 16:02:54 +0000] [7] [INFO] Shutting down: Master
Але так як поди/контейнери вмирають з кодом 137, то вони були вбиті з SIGKILL, бо коли Docker або інший container runtime не може зупинити процес з PID 1 з SIGKILL – то він відправляє SIGKILL всім процесам в контейнері.
Тобто:
спочатку відправляється SIGTEM до PID 1
через 10 секунд відправляється SIGKILL до PID 1
якщо і це не допомогло – то SIGKILL відправляється всім процесам в контейнері
Наприклад, це можна зробити передавши Session ID (SID) команді kill.
В Kubernetes окрім метрик та логів з контейнерів ми маємо змогу отримувати інформацію про роботу компонентів за допомогою Kubernetes Events.
В евентах зазвичай зберігається інформація про статус подів (створення, Evict, kill, ready або not-ready статус подів), про WorkerNodes (статус серверів), про роботу Kubernetes Scheduler (неможливість запуску поду, тощо).
Типи Kubernetes Events
В цілому, всі ці евенти можна поділити на такі типи:
Failed events: коли виникає проблема з маніфестом або образом, з якого потрібно створити контейнер (ImagePullBackOff, CrashLoopBackOff)
Scheduler events: проблеми с запуском поду на WorkerNode, наприклад – коли Scheduler не може знайти ноду з достатніми ресурсами, щоб задовольнити Pod requests
Volume events: проблеми з підключенням PersistentVolume до поду (FailedAttachVolume, FailedMount)
Node events: проблеми в роботі WorkerNodes (NodeNotReady)
Kubernetes Events та kubectl
Отримати евенти можемо просто з kubectl – або зробивши kubectl describe pod <POD_NAME> чи kubectl decsribe deploy <DEPLOY_NAME>:
Або з kubectl get events, якому можна додати параметр --watch:
Також існує цікавий плагін podevents, який додає час евенту.
sloop – активний, система візуалізації евентів з можливістю фільтрації та пошуку
kspan – активний, створює OpenTelemetry Spans з евентів, які потім можна перевіряти в системах типу Jaeger
kubernetes-event-exporter – активний, вміє відправляти евенти, мабуть, в усе, що взагалі існує – і AWS SQS/SNS, і Opsgenie, і Slack, і Loki – можливо, він буде наступний в моєму кластері, коли поточне рішення стане недостатнім
Grafana Agent (Grafana Alloy) – теж вміє працювати з евентами, і писати їх у вигляді логів в Loki
Але, як на мене, то простіше всього їх мати у вигляді логів, і потім з Loki RecordingRules створювати метрики, а з них графіки в Grafana та/або алерти.
Для цього є дуже проста система max-rocket-internet/k8s-event-logger, яка слухає Kubernetes API, отримує всі евенти, і записує їх у вигляді лога в JSON.
$ kubectl -n ops-monitoring-ns get pods -l "app.kubernetes.io/name=k8s-event-logger"
NAME READY STATUS RESTARTS AGE
k8s-event-logger-5b548d6cc4-r8wkl 1/1 Running 0 68s
Чого прям ну дуже не вистачає в цій системі – це доступу до серверів по SSH, без якого почуваєшся… Ну, наче DevOps, а не Infrastructure Engineer. Короче – доступ по SSH іноді прям треба, але – сюрпрайз – Karpenter з коробки не дає можливості додати ключ на ноди, які він менеджить.
Хоча, здавалося б – в чому проблема в EC2NodeClass передати ключ, як це робиться в Terraform resource "aws_instance"з параметром key_name?
Але – ОК. Нема, то й нема. Можливо, додадуть пізніше.
Тож що будемо робити сьогодні – по черзі спробуємо всі три рішення, спочатку кожне будемо робити руками, потім дивитись як його додати в нашу автоматизацію, і потім вирішимо який варіант буде найпростішим.
Варіант 1: AWS Systems Manager Session Manager та SSH на EC2
AWS Systems Manager Session Manager використовується для менеджменту EC2-інстансів. Взагалі він вміє досить багато, наприклад – слідкувати за патчами і апдейтами для пакетів, які встановлені на інстансах.
Зараз він нас цікавить тільки як система, яка дозволить виконати SSH на Kubernetes WorkerNode.
Для роботи потребує SSM-агента, який по дефолту є на всіх інстансах з Amazon Linux AMI.
Знаходимо ноди, які створені Kaprneter (у нас є окрема лейбла для них):
$ kubectl get node -l created-by=karpenter
NAME STATUS ROLES AGE VERSION
ip-10-0-34-239.ec2.internal Ready <none> 21h v1.28.8-eks-ae9a62a
ip-10-0-35-100.ec2.internal Ready <none> 9m28s v1.28.8-eks-ae9a62a
ip-10-0-39-0.ec2.internal Ready <none> 78m v1.28.8-eks-ae9a62a
...
AWS CLI: TargetNotConnected when calling the StartSession operation
Пробуємо підключитись – і отримуємо помилку “TargetNotConnected“:
$ aws --profile work ssm start-session --target i-011b1c0b5857b0d92
An error occurred (TargetNotConnected) when calling the StartSession operation: i-011b1c0b5857b0d92 is not connected.
Або через AWS Console:
Але і тут маємо помилку підключення – “SSM Agent is not online“:
Помилка виникає через те, що:
або в IAM-ролі, яка підключена до інстансу, нема дозволу на SSM
або EC2 запущено в приватній мережі, і агент не може підключитись до зовнішнього ендпоінту
SessionManager та політики для IAM
Перевіряємо – знаходимо IAM Role:
І підключені до неї політики – про SSM нема нічого:
Редагуємо політику – поки що руками, потім зробимо в коді Terraform:
Підключаємо AmazonSSMManagedInstanceCore:
І за хвилину-дві пробуємо ще раз:
SessionManager та VPC Endpoint
Інша можлива причина проблем підключення SSM-агенту до AWS – нема доступу з інстансу до ендпоінтів SSM:
ssm.region.amazonaws.com
ssmmessages.region.amazonaws.com
ec2messages.region.amazonaws.com
Якщо сабнет приватний, і має ліміти на зовнішні підключення – то можливо треба створити VPC Endpoint для SSM.
Але після фіксу IAM при підключенні з робочої машини з AWS CLI маємо помилку “SessionManagerPlugin is not found“:
$ aws --profile work ssm start-session --target i-011b1c0b5857b0d92
SessionManagerPlugin is not found. Please refer to SessionManager Documentation here: http://docs.aws.amazon.com/console/systems-manager/session-manager-plugin-not-found
В модулі версії 20.0 ім’я параметру змінилось – iam_role_additional_policies => node_iam_role_additional_policies, але у нас поки що версія 19.21.0, і роль додається таким чином:
Для Terraform тут буде потрібно в модулі EKS додавати node_security_group_additional_rules для доступу по SSH, і для VPC створювати EC2 Instance Connect Endpoint, бо у нас VPC та EKS створюються окремо.
Втім, тут треба передавати SecurityGroup ID з кластеру, а кластер у нас створюється після VPC, тому виникає проблема “куриця-яйце”.
Взагалі з Instance Connect виглядає якось трохи більш складно, чим з SSM, бо більше змін в коді, ще й в різних модулях.
Втім – варіант робочий, і якщо ваша автоматизація дозволяє – то можна використовувати його.
Варіант 3: дідовський спосіб з SSH Public Key через EC2 User Data
Ну і самий старий і, можливо, простий варіант – це самому створити SSH-ключ, і додавати його публічну частину на EC2 при створені інстансу.
З недоліків тут те, що додавати таким чином багато ключів буде складно, та й взагалі EC2 User Data іноді може вилізти боком, але якщо потрібно додати тільки один ключ, якийсь “супер-адмін” на крайній випадок – то цілком валідний варіант.
$ ssh-keygen
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/setevoy/.ssh/id_ed25519): /home/setevoy/.ssh/atlas-eks-ec2
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/setevoy/.ssh/atlas-eks-ec2
Your public key has been saved in /home/setevoy/.ssh/atlas-eks-ec2.pub
...
Публічну частину можемо зберігати в репозиторії – копіюємо її:
Далі трохи костилів: EC2NodeClass у нас створюється з Terraform через ресурс kubectl_manifest. Найпростіший варіант, який поки що прийшов в голову – це додати публічний ключ в variables, і потім використати в kubectl_manifest.
Пізніше мабуть перенесу такі ресурси в окремий Helm-чарт, і зроблю більш красиво.
Поки що створюємо нову змінну:
variable "karpenter_nodeclass_ssh" {
type = string
default = "ssh-ed25519 AAA***VMO setevoy@setevoy-wrk-laptop"
description = "SSH Public key for EC2 created by Karpenter"
}
AWS SessionManager: виглядає як найпростіший варіант з точку зору автоматизації, рекомендований самим AWS, але треба подумати, як робити той же scp через нього (хоча це начебто можливо через додаткові костилі – див. .SSH and SCP with AWS SSM)
AWS EC2 Instance Connect: прикольна фіча від Амазону, але якось більш геморно в автоматизації, тому не наш варіант
“дідовський” SSH: ну, старе – перевірене 🙂 але я не дуже люблю User Data, бо іноді може призвести до проблем з запуском інстансів; втім – теж простий з точки зору автоматиазції, і дає звичний SSH без додаткових тєлодвіженій
Повернемось до цієї теми ще раз, але цього разу на EC2 в AWS, без Kubernetes.
Отже, що треба – це запустити якийсь VPN-сервіс для проекту, або мати доступ до всяких Kubernetes API/Kubernetes WorkerNodes/AWS RDS у приватних мережах.
Вибір тут, в принципі, є – і AWS VPN, і ванільний OpenVPN, і багато іншого.
Але я Pritunl користувався вже в декількох проектах, він має приємний інтерфейс, основні можливості VPN доступні у Free версії – тож вай нот?
Що таке Pritunl
Фактично, Pritunl – це обгортка над звичайним OpenVPN сервером. Повністю сумісний, використовує однакові конфіги, і так далі.
Вміє в інтеграцію з AWS VPC – https://pritunl.com/vpc, але мені не дуже хочеться, щоб хтось автоматом міняв таблиці маршрутизації.
Сетап мережі в AWS у нас доволі простий, і поки що все можна менеджити самому – більше контролю, більше розуміння, що може піти не так.
Ну і плюс ця інтеграція наче доступна тільки в Enerprize – Pritunl Pricing.
У Pritunl дві основні концепції – Organization та Server:
Server описує конфіг для OpenVPN – порти, роути, DNS
Organization описує юзерів
Organization підключається до Server
Далі, юзер завантажує файл .ovpn, і підключається будь-яким VPN-клієнтом. Наскільки пам’ятаю, навіть дефолтний клієнт на macOS працював з ним без проблем.
Pritunl та Terraform
На попередньому проекті ми мали Pritunl в Kubernetes, але мені ця ідея якось не дуже подобається, бо, імхо, VPN має бути окремим сервісом.
Якщо говорити про Terraform, то є цікавий Pritunl Provider – але йому потрібен API ключ, який в Pritunl доступний тільки в Enerprize.
Ще є готовий код з Terraform тут – Pritunl VPN, але мені якось простіше підняти власну EC2 у власній VPC.
$ ssh-keygen
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/setevoy/.ssh/id_ed25519): /home/setevoy/.ssh/atlas-vpn
...
Публічну частину можемо зберігати в репозиторії – створюємо каталог, і копіюємо її:
Описуємо SecurityGroup – дозволяємо SSH тільки з цього IP, у vpc_id використовуємо local.vpc_out.vpc_id.
Додаємо порти – 80 для Let’s Encrypt, який використовується Pritunl, 443 – для доступу до його адмінки, тут знов тільки з мого IP, 10052 UPD – для клієнтів VPN:
Використовуючи data "aws_ami", знайдемо AWS AMI з Ubuntu.
Я спочатку пробував Pritunl запустити на Amazon Linux, але той yum і окремі репозиторії – це якась біда, на Ubuntu завелось без проблем:
data "aws_ami" "ubuntu" {
most_recent = true
filter {
name = "name"
values = ["ubuntu/images/hvm-ssd/ubuntu-*-22.04-amd64-server-*"]
}
filter {
name = "virtualization-type"
values = ["hvm"]
}
owners = ["099720109477"] # Canonical's official AWS account ID for Ubuntu AMIs
}
Але використовуючи data "aws_ami" майте на увазі, що коли вийде якась обнова, то AWS створить новий AMI, і при наступному запуску вашого Terraform-коду він підтягне новий ID, і запропонує перестворити відповідну EC2.
Аби мати одну і ту ж саму адресу, зробимо її окремим ресурсом:
resource "aws_eip" "vpn_eip" {
domain = "vpc"
}
AWS Route53 VPN record
Відразу створимо запис в DNS.
В variables.tf задаємо ID зони в Route53 та її ім’я:
variable "route53_ops_zone" {
type = object({
name = string
id = string
})
default = {
name = "ops.example.co"
id = "Z02***OYY"
}
}
І в main.tf описуємо сам запис:
resource "aws_route53_record" "vpn_dns" {
zone_id = var.route53_ops_zone.id
name = "vpn.${var.route53_ops_zone.name}"
type = "A"
ttl = 300
records = [aws_eip.vpn_eip.public_ip]
}
Тепер у нас буде запис виду “vpn.ops.example.co IN A <EC2_EIP>.
AWS EC2 та установка Pritunl
І, врешті-решт, описуємо сам EC2, використовуючи ресурси, які створили вище:
ami – беремо з data.aws_ami.amazon_linu
key_name – беремо з aws_key_pair.vpn_key.key_name
vpc_security_group_ids – з SG, яку створюємо тут же
subnet_id, де створювати EС2 – беремо з local.vpc_out.vpc_public_subnets_ids
Тут же відразу додаємо встановлення Pritunl – див. документацію [Other Providers] Ubuntu 22.04, але вона місцями крива, тому, можливо, краще зробити установку руками після створення інстансу.
Ну, або таки додати в user_data – принаймні на момент написання з кодом нижче це працювало.
У випадку проблем з EC2 user_data – перевіряйте лог /var/log/cloud-init.log, і спробуйте запустити скрипт вручну – він має бути у файлі типу /var/lib/cloud/instance/scripts/part-001.
Майте на увазі, що user_data викликається тільки при створенні інстансу:
Відкриваємо vpn.ops.example.co:443, на помилку ERR_CERT_AUTHORITY_INVALID поки не звертаємо уваги – Let’s Encrypt згенерить сертифікат після налаштувань Pritunl.
Передаємо setup-key, адресу MongoDB можна лишити по дефолту:
Чекаємо апдейту MongoDB:
Коли відкриється вікно логіна – на сервері виконуємо pritunl default-password:
Генеруємо новий пароль, яким будемо користуватись вже постійно:
$ pwgen 12 1
iBai1Aisheat
І задаємо основні параметри Pritunl – тут тільки логін/пароль та адреси:
Якщо забули новий пароль – можна скинути з pritunl reset-password.
Error getting LetsEncrypt certificate check the logs for more information.
При проблемах з Let’s Ecnrypt – перевіряємо лог /var/log/pritunl.log, там все буде:
root@ip-10-0-1-25:/home/ubuntu# tail -f /var/log/pritunl.log
File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/handlers/settings.py", line 1112, in settings_put
acme.update_acme_cert()
File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/acme.py", line 73, in update_acme_cert
cert = get_acme_cert(settings.app.acme_key, csr, cmdline)
File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/acme.py", line 45, in get_acme_cert
certificate = acmetiny.get_crt(
File "/usr/lib/pritunl/usr/lib/python3.9/site-packages/pritunl/acmetiny.py", line 138, in get_crt
raise ValueError("Challenge did not pass for {0}: {1}".format(domain, authorization))
ValueError: Challenge did not pass for vpn.ops.example.co: {'identifier': {'type': 'dns', 'value': 'vpn.ops.example.co'}, 'status': 'invalid', 'expires': '2024-06-07T13:32:30Z', 'challenges': [{'type': 'http-01', 'status': 'invalid', 'error': {'type': 'urn:ietf:params:acme:error:dns', 'detail': 'DNS problem: NXDOMAIN looking up A for vpn.ops.example.co - check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for vpn.ops.example.co - check that a DNS record exists for this domain', 'status': 400}, 'url': 'https://acme-v02.api.letsencrypt.org/acme/chall-v3/357864308812/RHhMwA', 'token': 'KZLx4dUxDmow5uMvfJdwbgz5bY4HG0tTQOW2m4UvFBg', 'validated': '2024-05-31T13:32:30Z'}]}
acme_domain = "vpn.ops.example.co"
Домен новий – Let’s Encrypt про нього ще не знає.
Чекаємо кілька хвилин, і пробуємо ще раз.
Успішна реєстрація сертифікату в логах має виглядати так:
У випадку помилки “ERROR: Cannot open TUN/TAP dev /dev/net/tun: No such device” на Linux – спробуйте перезавантажитись. В мене ядро було оновлене, і давно не ребутався.
Перевіряємо локальні роути:
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.3.1 0.0.0.0 UG 600 0 0 wlan0
0.0.0.0 192.168.3.1 0.0.0.0 UG 1002 0 0 enp2s0f0
10.0.0.0 172.16.0.1 255.255.0.0 UG 0 0 0 tun0
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
...
Все гуд – в Інтернет, 0.0.0.0, ходимо старим маршрутом, через домашній роутер, а у VPC, 10.0.0.0 – через 172.16.0.1, наш VPN.
Спробуємо:
$ traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 _gateway (192.168.3.1) 1.617 ms 1.550 ms 1.531 ms
...
9 one.one.one.one (1.1.1.1) 17.265 ms 17.246 ms 18.600 ms
Окей, через домашній роутер.
І до якогось серверу в AWS VPC:
$ traceroute 10.0.42.95
traceroute to 10.0.42.95 (10.0.42.95), 30 hops max, 60 byte packets
1 172.16.0.1 (172.16.0.1) 124.407 ms 124.410 ms 124.417 ms
...
Через VPN.
І навіть SSH до інстансів в приватній мережі працює:
$ systemctl start pritunl-org.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ====
Authentication is required to start 'pritunl-org.service'.
Ще раз роути:
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.3.1 0.0.0.0 UG 100 0 0 enp2s0f0
0.0.0.0 192.168.3.1 0.0.0.0 UG 600 0 0 wlan0
0.0.0.0 192.168.3.1 0.0.0.0 UG 1002 0 0 enp2s0f0
10.0.0.0 172.16.0.1 255.255.0.0 UG 0 0 0 tun0
Все є.
Додаємо в автостарт:
$ systemctl enable pritunl-org.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-unit-files ====
Authentication is required to manage system service or unit files.
Authenticating as: root
Password:
==== AUTHENTICATION COMPLETE ====
Created symlink /etc/systemd/system/multi-user.target.wants/pritunl-org.service -> /etc/systemd/system/pritunl-org.service.
Хоча в заголовку цього поста я вказав “Helm Charts”, але з коробки і з дефолтними параметрами Renovate виконає перевірку просто всього, що є в репозиторії і має якісь versions та dependencides.
Ну і коли я писав, що Dependabot “швидко і просто конфігуриться“, то у випадку з Renovate це взагалі фактично робиться в кілька кліків і працює просто з коробки.
Підключення Renovate до GitHub
Переходимо на сторінку Renovate GitHub App, клікаємо Install, вибираємо в які репозиторії його підключити.
Я поки для тестів додам тільки в один репозиторій з нашим моніторингом де маємо Terraform та Helm:
Переходимо до репозиторію, і маємо відкритий Pull Request для ініціалізації Renovate:
Ііі… В принципі – це все 🙂
Налаштування Renovate
В цьому PR маємо створений файл renovate.json з мінімальним конфігом:
Крім того, Renovate відразу визначив, які пакети в цьому репозиторії є:
І відразу визначає, що треба оновити:
А на сторінці репозиторію на developer.mend.io побачимо всі деталі перевірки:
Тепер можемо додати трохи свої параметрів, яких прям дуже багато, бо Renovate дозволяє дуже гнучко налаштувати ваші перевірки – див. всі на Configuration Options.
Наприклад, додамо розклад запуску, лейбли та будемо PR відразу асайнити на мене:
З часом, коли проект росте, то рано чи пізно постане питання про апгрейд версій пакетів, модулів, чартів.
Робити це вручну, звісно, можна – але тільки до якоїсь межі, бо врешті-решт ви просто фізично не зможете моніторити та оновлювати все.
Для автоматизації таких процесів існує багато рішень, але найчастіше зустрічаються два – Renovate та Dependabot.
За результатами опитування в UkrOps Slack, Renovate набрав набагато більше голосів, і в принципі він вміє більше, ніж Dependabot.
З іншої сторони – Dependabot вже є в GitHub репозиторіях, доступний у всіх тарифних планах, тож якщо ви використовуєте GitHub – то для налаштування Dependabot вам просто потрібно додати води додати файл конфігурації. Хоча, трохи забігаючи наперед – Renovate налаштовується ще простіше, але про це в наступному пості – Renovate: GitHub та Helm Charts versions management.
Взагалі, Dependabot можна мати майже на всіх платформах – GitHub, Github Enterprise, Azure DevOps, GitLab, BitBucket та AWS CodeCommit, див. How to run Dependabot.
Але – це для мене був прям surprize-surprize – Dependabot не вміє в Helm-чарти. Хоча з Terraform працює, і вже є в деяких наших репозиторіях з Python-кодом, тож для початку давайте глянемо на нього.
Знов-таки, забігаючи наперед – Renovate мені зайшов набагато більше, і ми будемо використовувати його.
Налаштування Dependabot
Отже, як це працює:
в репозиторії створюється файл конфігурації Dependabot
в ньому описується що саме він має перевіряти – бібліотеки pip, модулі Terraform тощо
описується що саме цікавить – secrity updates, або versions updates
при знаходженні апдейтів – Dependabot створює Pull Request, в якому додає деталі по апдейту
Що можемо моніторити з Dependabot в контексті Terraform – це версії провайдерів та модулів.
Наприклад, маємо два файли – versions.tf, де задаються версії провайдерів, і файл lambda.tf, де використовуємо кілька модулів – terraform-aws-modules/security-group/aws, terraform-aws-modules/lambda/aws і інші:
Тепер, щоб Dependabot почав моніторити версії в них – створюємо каталог .github, і в ньому файл dependabot.yml:
Але для Dependabot ці сікрети необхідно задавати окремо – не в Actions secrets and variables > Actions, а в Actions secrets and variables > Dependabot:
Додаємо йому новий сікрет – і тепер перевірка працює:
Dependabot та приватні registries/repositories
Серед іншого, у нас є власні модулі Terraform, які зберігаються в приватному репозиторії.
При доступі до них – Dependabot сфейлить перевірку з помилкою “Dependabot can’t access ORG_NAME/atlas-tf-modules“:
Варіант перший – додати цей репозиторій або інший registry явно в файлі dependabot.yml – див. Configuring private registries.
Варіант другий – це просто клікнути Grant access, що відкриє доступ до репозиторію для всіх репозиторіїв в організації.
Або зробити вручну – переходимо в Settings організації > Code security > Global settings, і в Grant Dependabot access to private repositories додаємо доступ до потрібного репозиторію:
Ручний запуск Dependabot
Тепер, як додали доступ – повертаємось до репозиторію, переходимо в Insights > Dependency graph > Dependabot, клікаємо Check for updates:
І перевірка запущена:
В цілому, на цьому все. Тепер будемо мати апдейти для Terraform без необхідності самому підписуватись на всі репозиторії.
Іноді під час деплою Helm-чартів може з’являтись помилка “UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress“:
Виникати може через те, що попередній деплой не відбувся через помилки в чарті, або втрачений зв’язок між білд-машиною та Kubernets-кластером.
Перевіряємо статус релізу з ls --all:
$ helm -n dev-backend-api-ns ls --all
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
dev-backend-api dev-backend-api-ns 590 2024-05-23 09:11:51.332096671 +0000 UTC pending-upgrade kraken-0.1.0 1.16.0
І бачимо, що дійсно – маємо “pending-upgrade” замість “deployed“.
Також можна глянути з helm history – що там відбувалося до цього і який статус зараз:
І знов бачимо той самий статус “Preparing upgrade” замість “Upgrade complete“.
Окей, давайте фіксити.
Перший варіант – the hard way – просто видалити реліз з helm uninstall, і передеплоїти з helm upgrade --install, але це призведе до видалення всіх ресурсів, які були створені цим чартом.
Інший варіант – зробити helm rollback до попереднього стабільного деплою.
В цьому кейсі це був 587 – Upgrade complete.
Виконуємо:
$ helm -n dev-backend-api-ns rollback dev-backend-api 587
Rollback was a success! Happy Helming!
Перевіряємо статус тепер:
$ helm -n dev-backend-api-ns ls --all
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
dev-backend-api dev-backend-api-ns 591 2024-05-23 13:01:36.905101349 +0300 EEST deployed kraken-0.1.0 1.16.0
Або:
$ helm -n dev-backend-api-ns status dev-backend-api
NAME: dev-backend-api
LAST DEPLOYED: Thu May 23 13:01:36 2024
NAMESPACE: dev-backend-api-ns
STATUS: deployed
REVISION: 591
TEST SUITE: None
Перезапускаємо джобу в GitHub Actions – і все працює.
Ще одна крута фіча, яку Амазон показав ще на минулому re:Invent в листопаді 2023 – це зміни в тому, як AWS Elastic Kubernetes Service виконує аутентифікацію та авторизацію юзерів. При чому це стосується не тільки саме користувачів кластеру, а і WorkerNodes.
Перший пост цієї “серії” (яка взагалі не планувалась як серія) – я написав ще у 2022, коли вперше довелося почати розбиратись з електрикою і тим, як забезпечити електрохарчування вдома під час відключень:
іноді інвертор починає пищати під час роботи, і я поки не зрозумів чому (5 коротких звукових сигналів – хтось, може, в курсі?)
Маємо API-сервіс в Kubernetes, який періодично видає 502, 503, 504 помилки.
Колись вже трохи писав про Pritunl – 
Depndabot (див. 
З часом, коли проект росте, то рано чи пізно постане питання про апгрейд версій пакетів, модулів, чартів.
Іноді під час деплою Helm-чартів може з’являтись помилка “UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress“:
