Ще один цікавий анонс з останнього re:Invent – це те, що в CloudWatch додали можливість збирати метрики із зовнішніх ресурсів (див. дуже цікавий доклад AWS re:Invent 2023 – Cloud operations for today, tomorrow, and beyond (COP227)). Тобто тепер ми можемо створювати графіки та/або алерти не тільки з дефолтних метрик самого CloudWatch – але й за… Читати далі »
В цікаві часи живемо. Отже, поговоримо про дуже гучний запуск Amazon Q – нової системи від AWS, яка має допомогти нам, інженерам і не тільки, в роботі. Сам Amazon його називає “AI-powered assistant”, по факту для нас, як інженерів, це просто chatbot, з яким ми можемо поговорити, щоб отримати допомогу у розв’язанні якихось проблем або… Читати далі »
Що маємо: є у нас Kubernetes cluster, на якому скейлінгом WorkerNodes займається Karpenter, який для NodePool має параметр disruption.consolidationPolicy=WhenUnderutilized, тобто він буде намагитись “ущільніти” розміщеня подів на нодах так, щоб максимально ефективно використати ресурси CPU та Memory. В цілому все працює, але це призводить до того, що досить часто перестворюються WorkerNodes, а це викликає “переселення”… Читати далі »
Зараз ми вміємо збирати логи API Gateway та CloudWatch Logs, див. Loki: збір логів з CloudWatch Logs з використанням Lambda Promtail. Але в процесі міграції в Kubernetes у нас з’явились Application Load Balancers, які вміють писати логи тільки в S3, і нам треба навчитись збирати логи і звідти. Формат логу AWS ALB див. у Access… Читати далі »
В пості Prometheus: запуск Pushgateway у Kubernetes з Helm та Terraform писав про те, як для Prometheus додати Pushgateway, який дозволяє використовувати Push-модель замість Pull, тобто – експортер може відправити метрики прямо в базу замість того, щоб чекати, коли до нього прийде сам Prometheus або VMAgent. У VictoriaMetrics з цим набагато простіше, бо ніякого Pushgateway… Читати далі »
Отже, Karpenter зробив ще один великий шаг до релізу, і у версії 0.32 вийшов з етапу Alpha до Beta. Давайте кратко подивимось на зміни – а вони досить суттєві, а потім виконаємо апгрейд на EKS з Karpneter Terraform module та Karpenter Helm chart. Сам процес установки Karpenter описував у пості Terraform: створення EKS, частина 3… Читати далі »
Отже, маємо розгорнутий кластер Kubernetes – див. серію Terraform: створення EKS, частина 1 – VPC, Subnets та Endpoints. Маємо GitHub Actions workflow для його деплою – див. GitHub Actions: деплой Dev/Prod оточень з Terraform. Прийшов час почати деплоїти наш бекенд в Kubernetes. Тут знов використаємо GitHub Actions – будемо білдити Docker-образ з API-сервісом бекенду, зберігати… Читати далі »
В пості Loki: збір логів з CloudWatch Logs з використанням Lambda Promtail описано як можна збирати логи з CloudWatch Logs за допомогою Lambda-функції з Promtail, який пересилає логи в Grafana Loki. Що треба зробити зараз – це описати створення чотирьох таких функцій, по одній на кожен компонент проекту. Функції мають бути розміщені в приватних мережах… Читати далі »
Тепер, як маємо готовий код для розгортання кластеру AWS Elastic Kubernetes Service (див. Terraform: створення EKS, частина 1 – VPC, Subnets та Endpoints і наступні частини), прийшов час подумати про автоматизацію, тобто – про створення пайплайнів в CI/CD, які би виконували створення нових енвів для тестування фіч, або деплоїли апдейти на Dev/Prod оточення Kubernetes. І… Читати далі »
Остання, четверта частина, в якій ми встановимо решту контроллерів і додамо пару корисних дрібниць. Попередні частини: Terraform: створення EKS, частина 1 – VPC, Subnets та Endpoints Terraform: створення EKS, частина 2 – EKS кластер, WorkerNodes та IAM Terraform: створення EKS, частина 3 – установка Karpenter Планування Що нам залишилось зробити: встановити EKS EBS CSI Addon встановити ExternalDNS контролер… Читати далі »