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, та загалом має… Читати далі »
Отже, продовжуємо нашу подорож з міграцією GitLab до себе в Kubernetes. Див. попередні частини: GitLab: компоненти, архітектура, інфраструктура та запуск з Helm-чарту в Minikube GitLab: Helm-чарт values, залежності та деплой у Kubernetes з AWS S3 GitLab: міграція даних з GitLab cloud та процес backup-restore у self-hosted версії в Kubernetes В цілому – все працює, і… Читати далі »
Продовжуємо рухатись до запуску нашого self-hosted GitLab в production. Див. попередні частини – GitLab: компоненти, архітектура, інфраструктура та запуск з Helm-чарту в Minikube та GitLab: Helm-чарт values, залежності та деплой у Kubernetes з AWS S3. Міграція даних Ще дуже хотілося написати пост про міграцію даних з GitLab Cloud до self-hosted, але немає часу, та й… Читати далі »
GitLab для зберігання репозиторіїв по дефолту створює диск розміром 50 GB, чого для Production явно буде мало. Persistent Volume resize опція доступна як general availability з версії Kubernetes 1.24, див. Kubernetes 1.24: Volume Expansion Now A Stable Feature, а в Beta – з версії 1.11, див. Resizing Persistent Volumes using Kubernetes. Доступно для дисків AWS… Читати далі »
У Прометеуса є багато готових до використання експортерів, але інколи може з’явитися потреба у зборі своїх власних метрик. Для цього Прометеус надає клієнтські бібліотеки, які можемо використати для генерації метрик з потрібними лейблами. Експортер можна включити прямо в код вашого додатку, або можна запускати окремим сервісом, який буде звертатися до якогось вашого сервісу і отримувати… Читати далі »
Продовжуємо зайомство з GitLab та його деплоєм у Kubernetes. Перша частина – GitLab: компоненти, архітектура, інфраструктура та запуск із Helm-чарту в Minikube, тепер давайте готуватися деплоїти в AWS Elastic Kubernetes Service. Що робитимемо і де: деплоїмо в AWS з Helm-чарту, для початку якийсь “test env” Kubernetes – AWS EKS object store – AWS S3 PostgreSQL… Читати далі »