Це вже третя частина по розгортанню кластеру AWS Elastic Kubernetes Service з Terraform, в якій будемо додавати в наш кластер Karpenter. Вирішив винести окремо, бо виходить досить довгий пост. І вже в останній (сподіваюсь), четвертій частині, додамо решту – всякі контроллери. Попередні частини: Terraform: створення EKS, частина 1 – VPC, Subnets та Endpoints Terraform: створення… Читати далі »
Отже, з Терраформом трохи розібрались, згадали що до чого – час робити щось реальне. Перше, що будемо розгортати з Terraform – це кластер AWS Elastic Kubernretes Service та всі пов’язані з ним ресурси, бо зараз це зроблено з AWS CDK, і окрім інших проблем з CDK, вимушені мати EKS 1.26, бо 1.27 в CDK ще… Читати далі »
Готуємось переводити управління інфрастуктурою з AWS CDK на Terraform. Про планування того, як воно все може виглядати писав у Terraform: початок роботи та планування нового проекту – Dev/Prod та bootsrap, але тоді оминув одну досить важливу опцію – створення lock для state-файлів. Блокування стейт-файлів використовується для того, щоб уникнути ситуацій, коли запускається кілька інстансів Terraform… Читати далі »
Продовжуємо розвивати наш стек моніторингу. Див. VictoriaMetrics: створення Kubernetes monitoring stack з власним Helm-чартом. Що хочеться: зробити доступ девелоперам, щоб вони могли в Alertmanager самі виставляти Silence для алертів аби не спамити в Slack, див. Prometheus: Alertmanager Web UI и Silence алертов. Для того, щоб забезпечити безпечний доступ до нього можна використати рішення від VictoriaMetrics… Читати далі »
На всіх попередніх проектах, де був Kubernetes я використовував AWS Elastic Kubernetes Service, а для скейлінгу його WorkerNodes – Cluster Autoscaler (CAS), бо в принципі інших варіантів раньше не було. В цілому, CAS працював добре, проте в листопаді 2020 AWS випустив власне рішення для скейлінгу нод для EKS – Karpenter, і якщо спочатку відгуки були… Читати далі »
Kubernetes дозволяє дуже гнучко керувати тим, як його Pods будуть розташовані на серверах, тобто WorkerNodes. Це може бути корисним, якщо вам треба запускати под на специфічній конфігурації ноди, наприклад – WorkerNode повинна мати GPU, або SSD замість HDD. Інший приклад, це коли вам потрібно розміщати окремі поди поруч, щоб зменшити затримку їхньої комунікації, або зменшити… Читати далі »
Фукція в AWS Lambda пише логи в CloudWatch Logs, звідки ми через lambda-promtail забираємо їх в Grafana Loki, звідки потім можемо використати в графіках Grafana. Що треба зробити: в логах пишеться час “Init duration” та “Max Memory Used”. В CloudWatch таких метрик нема, а нам цікаво мати графік по цим данним, бо це може бути… Читати далі »
Отже, маємо Loki, встановленую з чарту у simple-scale mode, див. Grafana Loki: архітектура та запуск в Kubernetes з AWS S3 storage та boltdb-shipper. Працює Loki все в AWS Elastic Kubernetes Service, встановлено з Loki Helm chart, в ролі long-term store використовуємо AWS S3, а для роботи з індексами Loki – BoltDB Shipper. У Loki в… Читати далі »
Трафік в AWS взагалі досить цікава та місцями складна штука, колись писав окремо про це у пості AWS: Cost optimization – обзор расходов на сервисы и стоимость трафика в AWS – прийшов час трохи повернутися до цієї теми. Отже, в чьому проблема: в AWS Cost Explorer помітив, що кілька днів поспіль маємо зростання витрат на… Читати далі »
Зараз маємо VictoriaMetrics + Grafana на звичайному EC2-інстансі, запущені з Docker Compose – то був Proof of Concept, прийшов час запускати “по-дорослому” – в Kubernetes, і всі конфіги вже винести в GitHub. У VictoriaMetrics є чарти під кожен компонент, див. Victoria Metrics Helm Charts, і є чарти для запуску VictoriaMetrics Operator та victoria-metrics-k8s-stack – аналог… Читати далі »