Зараз маємо VictoriaMetrics + Grafana на звичайному EC2-інстансі, запущені з Docker Compose – то був Proof of Concept, прийшов час запускати “по-дорослому” – в Kubernetes, і всі конфіги вже винести в GitHub. У VictoriaMetrics є чарти під кожен компонент, див. Victoria Metrics Helm Charts, і є чарти для запуску VictoriaMetrics Operator та victoria-metrics-k8s-stack – аналог… Читати далі »
Зберігання даних доступу у Kubernetes Secrets має важливий недолік, бо вони доступні тільки всередені самого Kubernetes кластеру. Щоб зробити їх доступними зовнішнім сервісам – можемо використати Hashicorp Vault і інтегрувати його з Kubernetes за допомогою таких рішень, як vault-k8s, або скористуватись сервісами від AWS – Secrets Manager або Parameter Store. Інтеграція AWS Secrets Manager та… Читати далі »
Продовжимо про AWS CDK та Python. Пишу не тому, що подобається, а тому, що в інтернеті прикладів ну якось зовсім мало, тож нехай будуть хоча б тут. Отже, маємо кластер, маємо пару контролерів. Наче все готово – почав встановлювати чарт VictoriaMetrics, і все завелося окрім поду з VMSingle, який завис в статусі Pending. “VolumeBinding”: binding… Читати далі »
Отже, маємо AWS EKS кластер, створений з AWS CDK та Python – AWS: CDK – створення EKS з Python та загальні враження від CDK та маємо уявлення, як працює IRSA – AWS: EKS, OpenID Connect та ServiceAccounts. Наступним кроком після розгортання самого кластеру треба налаштувати OIDC Identity Provider в AWS IAM, та додати два контролери… Читати далі »
Зараз сетаплю новий ЕКС кластер, і серед інших компонентів запускаю в ньому ExternalDNS, який використовує Kubernetes ServiceAccount для аутентифікації в AWS, щоб мати змогу вносити зміни до доменної зони в Route53. Однак забув налаштувати Identity Provider в AWS IAM, і ExternalDNS видав помилку: level=error msg=”records retrieval failed: failed to list hosted zones: WebIdentityErr: failed to… Читати далі »
Terraform то чудово, але поки що вирішили перші кластера AWS EKS створювати за допомогою AWS CDK, бо по-преше – він вже є на проекті, по-друге – самому цікаво спробувати новий інструмент. Тож сьогодні розглянемо що з цього вийшло, та як створювався кластер і необхідні ресурси. Про перше знайомство з СDK писав тут – AWS: CDK… Читати далі »
AWS Fargate – ще одне serverless-рішення від Amazon, яке бере на себе управління інфраструктурою, позбавляючи користувача необхідності витрачати час на налаштування ЕС2-інстансів, операційної системи, систем управління контейнерами тощо. Взагалі, коли знайомився з Fargate, натрапив на чудове відео з AWS re:Invent 2022, де дуже добре розказано (і показано) про Shared Responsibility model у AWS – за… Читати далі »
Окрім Horizontal Pod Autoscaler (HPA), який створює додаткові поди якщо наявні починають використовувати більше CPU/Memory, ніж налаштовано у лімітах HPA, існує і Vertical Pod Autoscaler (VPA), який працює за іншою схемою: замість горизонтального масштабування, тобто збільшення кількості подів, він змінює resources.requests поду, що призводить до того, что Kubernetes Scheduler “переселяє” цей под на іншу WorkerNode,… Читати далі »
Маємо на проекті багато AWS Lambda функцій, з яких девелопери хочуть мати можливість відправляти метрики до нашого Prometheus, щоб додати власних алертів та графіків у Grafana. Для цього у функціях використовується бібліотека Prometheus, яка дозволяє ці метрики створювати (див. Prometheus: створення Custom Prometheus Exporter на Python), але ж ми не маємо змоги нормально отримати ці… Читати далі »
Knative – система, яка дозволяє використовувати Serverless модель розробки у Kubernetes. По суті, Knative можна уявляти собі як ще один рівень абстракції, який дозволяє девелоперам не поринати в деталі деплойменту, скелінгу та нетворкінгу у “vanilla” Kubernetes. Розробка самого Knative була розпочта у Google за співучастю таких компаній, як IBM, Pivotal, Red Hat, та загалом має… Читати далі »