Переезд с облака на свои сервера — это не просто техническая миграция, а настоящая проверка на прочность для всей команды и бизнеса в целом. В статье я постараюсь объяснить, опираясь на свой опыт, почему облачные решения не всегда оказываются универсальным спасением, с какими неожиданными сложностями мы столкнулись и какие компромиссы пришлось принимать. Это история не только про железо и Hard‑скиллы, но и про людей, процессы и принятие решений в условиях ограниченного бюджета и рисков.

Используете готовые операторы в Kubernetes? Я тоже... Но с какого‑то момента я начал задаваться вопросом: «а как люди их пишут?». И я нашел ответ!

В этой статье я наглядно покажу, как создать свой кастомный оператор в Kubernetes на Go при помощи kubebuilder. Оператор позволит отслеживать изменения ресурсов в кластере, а затем отправлять уведомления в Telegram или другие мессенджеры. Какие ресурсы «трекать» будем описывать через кастомные ресурсы (Custom Resource). Погнали!

Всем привет! Если вы работаете с Kubernetes, то, скорее всего, используете kubectl, kustomize или Helm для развёртывания сервисов в кластере. Про последнюю утилиту я уже писал статью — можно посмотреть тут. Тогда я рассказал о своём опыте внедрения этого инструмента для собственных нагрузок и сравнил подходы kubectl apply и helm install.

Управление конфигурацией в Kubernetes может осуществляться с помощью различных инструментов. Помимо Helm, можно использовать просто YAML-манифесты или же kustomize. Для каждого из этих инструментов предусмотрена своя команда.

В данной статье мы рассмотрим подход GitOps для K8s-кластеров и применим такой инструмент, как Argo CD.

Есть множество путей развернуть свой Kubernetes. Все они разные, выбор зависит от вашего бюджета, от того, какие задачи вы планируете решать, для каких нагрузок и что в конечном итоге вы планируете получить. В этой статье мы быстро пройдёмся по различным способам инсталляции, а затем попробуем развернуть свой K8s кластер на виртуальных машинах, воспользовавшись гипервизором второго типа (VirtualBox). Но это будет не условная Ubuntu, на которую мы будем ставить необходимые компоненты, а целая операционная система, разработанная специально для Kubernetes — Talos Linux!

Не задумывались ли вы когда-нибудь над тем, чтобы знать о каждом входе на ваши сервера? Меня охватила такая же паранойя: а вдруг, когда я сплю, на мой сервер заходит домовой и творит там ужасы? Хотя логин на наши сервера и запрещен по паролю, а SSH-ключи есть только у меня, в любом случае это вызывает большие опасения.

В этой статье мы развёрнем через Terraform несколько серверов в Yandex.Cloud, а затем при помощи Ansible настроим необходимый софт на каждом сервере. У нас будет основной сервер c Loki (система агрегирования логов) и Grafana (инструмент для визуализации данных), на серверах, которые мы хотим отслеживать, будет установлен Promtail (агент для сбора и отправки логов). Мы разберёмся с тем, как отслеживать входы на сервер, а затем в удобном формате отправлять об этом уведомления в чат с помощью вышеуказанных сервисов.

Облачные вычисления уже давно стали неотъемлемой частью нашей жизни, и все больше компаний предоставляют свои услуги через облако. Облачные сервисы уже используются в различных отраслях. Однако, не все компании понимают, как использовать облако эффективно. Эта книга может помочь IT специалистам из разных отраслей лучше понять, как работает облако и какие преимущества оно даёт.

В книге "97 Things Every Cloud Engineer Should Know" вы найдете ответы на все интересующие вас вопросы по облачным вычислениям, независимо от вашего опыта работы в этой области. Статьи были написаны так, чтобы даже люди, не знакомые с облачными технологиями, могли легко разобраться в теме.

Бывало ли у вас такое, что вы совершали одни и те же действия из раза в раз и наконец-то решили избавиться от всей этой рутины? Но вы решили отложить это решение на некоторое время, в частности из-за занятости или лени. Но вот вы решаете взять себя в руки и всё изменить! Также было и со мной - и вот в конце концов я решился пойти на оптимизацию развертывания сервисов в Kubernetes при помощи Helm и написать об этом статью!

Я уже успел развернуть несколько приложений в Kubernetes. Но в последнее время взаимодействовать с ресурсами через kubectl становится невыносимо больно. Поэтому я решил осуществить свою давнюю затею - написать свой Helm чарт. Сегодня мы вместе с тобой, Хабрюзер, создадим свой чарт, который можно будет использовать для деплоя собственных приложений!

Мониторинг состояния серверов и приложении является одной из основных задач DevOps-инженера. Логирование помогает обнаружить проблемы, возникающие в запущенных сервисах, а также понять что на самом деле случилось в случае возникновения проблем. Методы и инструменты для мониторинга выбираются исходя из сервера, на котором разворачиваются приложения. Не важно где и как вы развернули свой K8s кластер - PaaS решение от облачного провайдера, на ВМ или даже на своём собственном ПК. В этой статье я бы хотел описать процесс развертвывания системы мониторинга и логирования в Kubernetes, начиная с установки кубера на свой сервер и заканчивая импортом готового дашборда.

Вам сказали развернуть систему мониторинга, вы выбрали связку Prometheus + Grafana. Развернули Grafana на своих серверах (VM/Docker/Kubernetes) и подключили Data Source Prometheus (а возможно вам еще сказали развернуть логирование и вы используете Grafana Loki) и далее по гайдам из ютуба начали создавать свои дашборды и настраивать алерты.

Все работает идеально, но в один момент вы начинаете думать о том, чтобы хранить созданные сущности Grafana в коде, чтобы их можно было легко восстановить в случае потери данных или же развернуть при создании новой среды (dev/prod). Экспортировать дашборды не составит труда, это можно сделать и через GUI, но как же источники данных, политики уведомлении, contact points и сами алерты?

Знакомая история? Возможно, что нет. А у меня да!

Всем привет! Я работаю Dev-Ops инженером в небольшой команде и мы уже 4-ый месяц используем Yandex Cloud для наших сервисов. Так сложилось, что с Kubernetes и облачными вычислениями я столкнулся впервые, поэтому многое приходится изучать на ходу, иногда на "горьком" опыте. На данный момент наши микросервисы развернуты в зональном кластере Kubernetes с одним рабочим узлом, по одной реплике на каждый Deployment. Это означает, что никакой отказоустойчивости и масштабируемости нет и при малейшей нагрузке приложения упадут.

Поэтому, пока нагрузка идет только от команды разработчиков, я решил заранее побеспокоиться об отказоустойчивости наших сервисов, развернутых в Yandex Managed Service for Kubernetes. Сегодня я разверну на своем облаке Kubernetes кластер и покажу как будет вести себя автомасштабируемое приложение под нагрузкой. Для управления инфраструктурой воспользуемся Terraform, для имитирования нагрузки сервисом Yandex Load Testing (в стадии Preview) от Yandex Cloud.