Маємо AWS Elastic Kubernetes Service, на якому розгорнуто стек VictoriaMetrics (див. VictoriaMetrics: створення Kubernetes monitoring stack з власним Helm-чартом). Треба перенести дані зі старого поду VMSingle на новий, на новому кластері, а для цього треба знайти ці дані на EC2. Note: щодо міграції даних VMSingle, то для неї є утиліта vmctl, десь в чернетках лежить… Читати далі »
Про запуск Nexus писав в пості Nexus: запуск в Kubernetes та налаштування PyPi caching repository, тепер до PyPi хочеться додати кешування Docker images, тим більш Docker Hub з 1-го квітня 2025 вводить нові ліміти – див. Docker Hub usage and limits (дяка @Anatolii). Робити будемо як завжди – спочатку вручну локально на робочій машині, подивимось,… Читати далі »
Продовжуємо міграцію з Grafana Loki на VictoriaLogs, і наступна задача – це перенести Recording Rules з Loki до VictoriaLogs, і оновити алерти. Recording Rules та інтеграцію з VMAlert до VictoriaLogs завезли відносно недавно, і цю схему ще не тестував. Тому спершу все зробимо руками, подивимось як це працює, які є нюанси, а потім будемо оновлювати… Читати далі »
У нас в Kubernetes запускаються GitHub Runner для білда і деплоя нашого Backend API, див. GitHub Actions: запуск Actions Runner Controller в Kubernetes. Але з часом ми звернули увагу, що на NAT Gateway бігає якось забагато трафіку – див. VictoriaLogs: дашборда в Grafana з AWS VPC Flow Logs – мігруємо з Grafana Loki. Проблема: трафік… Читати далі »
В попередньому пості – AWS: VPC Flow Logs – логи до S3 та Grafana dashboard з Loki ми створили дашборду в Grafana, яка відображає статистику використання NAT Gateway. Що саме нас там цікавило – це які Kubernetes Pods використовують найбільше байт, бо це напряму впливає на наші AWS Costs. І все наче добре з цією… Читати далі »
Подивились ми на наші витрати на AWS Load Balancers, і подумали, що треба трохи це діло привести в порядок. Чого хочеться: мати один LoadBalancer, і через нього роутити запити на різні Kubernetes Ingresses та Services в різних Namespaces. Перше, що спало на думку – це або додавати в Kubernetes кластер якийсь Service Mesh типу Istio… Читати далі »
В продовження теми AWS: VPC Flow Logs, NAT Gateways, та Kubernetes Pods – детальний обзор. Там ми розбирали роботу з VPC Flow Logs в цілому, і дізнались, як ми можемо отримувати інформацію про трафік з/до Kubernetes Pods. Але при використанні Flow Logs з CloudWatch Logs є одна проблема – це вартість. Наприклад, коли ми включаємо… Читати далі »
Ми користуємось GitHub Actions для деплоїв, і врешті-решт прийшли до того, що хочеться запускати Runners на своїх серверах в Kubernetes, бо: self-hosted GitHub Runners дешевші – фактично, платимо тільки за сервери, на яких запускаються джоби нам потрібно запускати SQL migrations на AWS RDS в приватних сабнетах перформанс – ми можемо використовувати будь-який тип AWS EC2… Читати далі »
Disruption budgets з’явились в версії 0.36, і виглядає як дуже цікавий інструмент для того, аби обмежити Karpenter в перестворенні WorkerNodes. Наприклад в моєму випадку ми не хочемо, аби EC2 вбивались в робочі часи по США, бо там у нас клієнти, а тому зараз маємо consolidationPolicy=whenEmpty, аби запобігти “зайвому” видаленню серверів та Pods на них. Натомість… Читати далі »
VictoriaLogs – відносно нова система для збору та аналізу логів, схожа на Grafana Loki, але – як і VictoriaMetrics в порівнянні з “ванільним” Prometheus – менш вибаглива до ресурсів CPU/Memory. Особисто я користуюсь Grafana Loki років 5, але до неї іноді буває дуже багато питань – і по документації, і по загальній складності системи, бо… Читати далі »