Kubernetes: правильный подход к ресурсным лимитам и requests

🔧 Часто недооценённая, но критичная тема для стабильности и производительности кластеров.


🎯 Зачем это важно?
Неверные значения requests и limits приводят либо к перерасходу ресурсов, либо к OOM, Throttling и подам, которые бесконечно перезапускаются. Особенно больно это бьёт по продакшену.


🚀 Как правильно настраивать ресурсы:

1. Понимай разницу между requests и limits:
- requests — это гарантированный минимум, который получит контейнер.
- limits — это максимум, выше которого контейнер не сможет использовать (CPU throttling или OOMKill для памяти).

2. CPU — без жестких лимитов:
- Лучше не указывать limits.cpu, чтобы избежать throttling.
- Но обязательно ставь requests.cpu, чтобы kube-scheduler мог правильно распланировать нагрузку.

3. Memory — всегда с лимитом:
- Память не отбирается — контейнер либо получает всю, либо OOM.
- Обязательно ставь и requests.memory, и limits.memory.

4. Используй VPA (Vertical Pod Autoscaler):
- Он поможет подобрать адекватные значения ресурсов на основе истории.
- ⚠️ На проде использовать осторожно — часто в "recommendation only" режиме.

5. Метрики в помощь:
- Используй kubectl top, metrics-server, Prometheus/Grafana для анализа потребления.
- Наблюдай за container_cpu_usage_seconds_total, container_memory_usage_bytes.

6. Профилируй и оптимизируй:
- Легковесный nginx или sidecar не должен просить 500Mi памяти.
- Java-приложение без указанных лимитов съест весь узел.


🧠 Вывод:
Грамотно выставленные ресурсы — это баланс между надёжностью и эффективным использованием нод. Не копируй requests/limits вслепую из интернета — мерь, анализируй, настраивай под свой ворклоад.


#devops #девопс

Подпишись 👉@i_DevOps

Cilicon - это приложение для macOS, использующее фреймворк виртуализации Apple для создания, предоставления и запуска эфемерных виртуальных машин CI с производительностью, близкой к нативной. В настоящее время оно поддерживает Github Actions, Buildkite Agent, GitLab Runner и произвольные скрипты.

В зависимости от ваших настроек, вы сможете запустить свой собственный CI в считанные минуты 🚀.


https://github.com/traderepublic/Cilicon

#devops #девопс

Подпишись 👉@i_DevOps

CI/CD как часы: 7 трюков для ускорения GitHub Actions 🚀

Иногда GitHub Actions начинает "плыть": воркфлоу, который вчера собирался за 5 минут, сегодня крутится 15+. Это не баг, а сигнал — пора оптимизировать пайплайн.

Вот подборка проверенных техник, чтобы ускорить и удешевить GitHub Actions без потери функциональности:


🔹 1. Используй actions/cache грамотно
Кэширование зависимостей (node_modules, .m2, vendor, pip) — простой способ ускорить билд на 30–70%.
Пример для npm:

- uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: ${{ runner.os }}-npm-

🔹 2. Разделяй и властвуй: job matrix
Параллельный запуск на разных версиях языка или ОС:

strategy:
  matrix:
    node: [16, 18]
runs-on: ubuntu-latest
steps:
  - uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node }}

🔹 3. Минимизируй checkout и ненужные шаги
Не всегда нужно тянуть весь git-репозиторий. Добавь:

- uses: actions/checkout@v4
  with:
    fetch-depth: 1

🔹 4. Self-hosted runners — когда билд тяжелый
Они быстрее, могут иметь предустановленные зависимости, и ты не платишь за минуты. Особенно актуально для Java и .NET проектов.

🔹 5. Используй workflow_dispatch для ручных прогонов
Иногда удобно запускать воркфлоу вручную — например, для релизов или прогонов e2e.

on:
  workflow_dispatch:

🔹 6. Логируй аккуратно — логи тоже грузят
Слишком подробные логи замедляют UI и усложняют дебаг. Используй ::group:: и ::endgroup:: для логических блоков.

🔹 7. Закладывай timeouts
Иногда job висит из-за одного зависшего шага. Укажи timeout, особенно для e2e или deploy-джобов:

jobs:
  build:
    timeout-minutes: 15

Вывод:
GitHub Actions — мощный инструмент, но требует тонкой настройки. Оптимизация кэша, параллелизм, сокращение шагов и self-hosted runners могут сэкономить часы CI и сотни долларов на GitHub billing.

#devops #девопс

Подпишись 👉@i_DevOps

🧑🏻‍💻Хотите стать Python-разработчиком, но не знаете, с чего начать?

Python — один из самых популярных и востребованных языков программирования. Он используется для создания веб-приложений, разработки игр, работы с данными и машинного обучения. С его простым синтаксисом легко начать даже тем, кто никогда не программировал.

Обучение «Python Developer. Basic» — это интенсивная программа, которая проведет вас от новичка до первого проекта. Вы освоите основы Python, научитесь работать с фреймворками FastAPI и Django, освоите работу с базами данных и API. Получите все необходимые навыки для позиции уверенного junior-разработчика.

🐍Узнайте подробности, оставьте заявку и получите скидку на обучение: https://vk.cc/cKTACa

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Глубокое погружение в запросы, лимиты и специфику использования CPU в Kubernetes

Джон Такер помогает разобраться с ключевыми аспектами управления ресурсами CPU в Kubernetes. Он объясняет разницу между запросами и лимитами, показывает их влияние на производительность приложений и делится практическими советами по настройке контейнеров. Если хотите улучшить работу кластеров, эта статья станет вашим гидом.

https://habr.com/ru/companies/flant/articles/898190/

#devops #девопс

Подпишись 👉@i_DevOps

CI/CD под нагрузкой: оптимизация пайплайна для high-load проектов 🚀

Когда репозиторий растёт, а коммиты летят один за другим — CI/CD превращается из помощника в тормоз. Но всё можно оптимизировать.

Зачем это нужно:
Медленные пайплайны тормозят разработку, повышают стоимость инфраструктуры и раздражают команду. Ниже — конкретные приёмы, как ускорить и облегчить CI/CD для high-load проектов.


🔹 1. Параллельность — наше всё
Используй matrix стратегии (в GitHub Actions) или parallel блоки (в GitLab CI). Тестируй сразу на нескольких версиях среды или запускай независимые шаги одновременно. Пример:

strategy:
  matrix:
    python-version: [3.10, 3.11]

🔹 2. Кэшируй агрессивно
Настрой кэш зависимостей, Docker-слоёв, результатов компиляции. Это сильно снижает время на сборку. В GitHub Actions:

- uses: actions/cache@v3
  with:
    path: ~/.cache/pip
    key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}

🔹 3. Разделяй и властвуй
Разбей монолитный пайплайн на микропайплайны: unit-тесты, линтеры, деплой — по отдельности. Используй needs: только при настоящей зависимости. Это повышает параллельность и устойчивость.

🔹 4. Запускай не всё подряд
Добавь paths: или only/except фильтры. Зачем гонять e2e, если изменился только README?

on:
  push:
    paths:
      - 'src/**'

🔹 5. Используй артефакты — разумно
Вместо перекомпиляции перед каждым шагом, сохраняй и передавай промежуточные сборки. Это особенно полезно для Java/Go/Node проектов.


Вывод:
Оптимизация пайплайна — не только про скорость. Это про контроль над процессом и уменьшение издержек. Начни с малого — кэш, фильтры, параллельность — и постепенно адаптируй под свой проект.

#devops #девопс

Подпишись 👉@i_DevOps

📕Открытый урок о NoSQL с Cassandra для разработчиков, администраторов, специалистов по базам данных, Data engineers, Backend и FullStack-разработчиков.

На открытом уроке 21 апреля в 20:00 мск мы погрузимся в тонкости работы c NoSQL в Cassandra.

📗В результате вы:
- Узнаете, как работает Cassandra и какие есть особенности про которые никто говорит;
- Разберетесь, как избежать и решать проблемы в работе Сassandra;
- Освоите техники и лайфхаки в Сassandra на практике.

Спикер Дмитрий Гурьянов — Team Lead команды разработки CRM-решений на платформе .NET в Промсвязьбанке, 9+ лет в разработке, работал в Microsoft над продуктом Bing, аспирант кафедры "Системы обработки информации и управления" в МГТУ им. Н.Э. Баумана.

👉Регистрируйтесь прямо сейчас, чтобы не пропустить мероприятие: https://vk.cc/cKWWeo

📙Все участники открытого урока получат скидку на курс "Базы данных"

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

CI/CD в 3 раза быстрее: секреты оптимизации GitHub Actions

GitHub Actions — мощный инструмент, но даже продвинутые пайплайны часто работают медленнее, чем могли бы. Потери времени = потери денег и developer experience. Вот как ускорить ваши воркфлоу без потери функциональности.

1. Используйте concurrency и cancel-in-progress

concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true

Это позволит отменять старые запуски одного и того же воркфлоу на той же ветке — особенно полезно при пушах в PR. Экономим минуты на каждом коммите.

2. Кешируйте всё, что можно

- name: Cache pip packages
uses: actions/cache@v3
with:
path: ~/.cache/pip
key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
restore-keys: |
${{ runner.os }}-pip-

То же касается node_modules, cargo, .m2, gradle — любые зависимости можно кэшировать, особенно если они скачиваются каждый раз.

3. Не бойтесь matrix + fail-fast: false

Запускайте параллельно всё, что можно: тесты на разных версиях языка, разных ОС, разных архитектурах.

strategy:
matrix:
python-version: [3.10, 3.11]
os: [ubuntu-latest, macos-latest]
fail-fast: false


4. Reusable workflows > копипаста

Выносите повторяющиеся шаги в отдельные .yml-воркфлоу и переиспользуйте их через workflow_call. Это упрощает поддержку и уменьшает ошибки.

5. Запускайте воркфлоу только при нужных событиях

on:
push:
branches: [main]
paths:
- 'src/**'
- '.github/workflows/**'

Зачем триггерить CI, если изменился только README?

Вывод:
Оптимизация CI/CD — это не про «поиграться с YAML». Это способ сэкономить время команды, ускорить релизы и избежать выгорания из-за бесконечного ожидания. Чем быстрее обратная связь — тем лучше продукт.

#devops #девопс

Подпишись 👉@i_DevOps

🚀 Разворачиваем Kubernetes-кластер за 5 минут с помощью Proxmox и k3s!

Автор статьи показывает, как быстро поднять кластер с помощью Proxmox и лёгкого дистрибутива K3s. Всё максимально просто:
- Устанавливаем Proxmox VE
- Создаём шаблон VM с Ubuntu
- Автоматизируем деплой через cloud-init
- Настраиваем кластер K3s в пару кликов

🔥 Идеально для домашней лаборатории или быстрой отладки!

00:04 Introduction
00:18 Why Use Mini PCs Over Cloud Computing for Personal / Hobby Projects
01:13 Installing Proxmox and Setting Up Cluster
02:12 Creating a VM for Kubernetes Worker Node
03:38 Installing Kubernetes on Ubuntu Server
04:14 Joining the New Node to the Kubernetes Cluster
05:19 Potential Applications of Your New Setup
05:30 Upcoming Projects and Channel Focus
06:02 Measuring Power Consumption with a Smart Plug
06:07 Conclusion and Farewell

https://dev.to/mihailtd/set-up-a-kubernetes-cluster-in-under-5-minutes-with-proxmox-and-k3s-2987

#devops #девопс

Подпишись 👉@i_DevOps

🧑🏻‍💻Хотите писать гибкий и читаемый код на Python? Пора раскрыть скрытые возможности встроенной библиотеки!

На открытом вебинаре 23 апреля в 20:00 мск мы познакомим вас с мощными инструментами стандартной библиотеки Python, которые сэкономят ваше время и помогут писать код без лишних зависимостей. Вы узнаете, как использовать модули, которые оптимизируют работу с данными, текстом и логированием.

Мы поговорим о модулях collections, re и logging — встроенных инструментах, которые делают код компактным и понятным. Это важный шаг к переходу на более высокие позиции в разработке.

⚡️Присоединяйтесь к открытому вебинару и получите скидку на большой курс "Python Developer. Basic": https://vk.cc/cKZI4x

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🎯 Terraform модули: избавься от копипасты навсегда

Terraform — мощный инструмент, но легко скатиться в хаос, когда одни и те же ресурсы повторяются в каждом проекте. Настало время структурировать всё по уму с помощью модулей.

Вот как модули помогут тебе:


🧩 Что такое модуль в Terraform?
Это переиспользуемый блок кода с входами (variables), выходами (outputs) и логикой, который можно вызывать из любого проекта. Примеры — VPC, ECS-сервис, ALB, CloudWatch-алерты.

📁 Структура модуля:

modules/
├── vpc/
│   ├── main.tf
│   ├── variables.tf
│   └── outputs.tf

🔄 Использование модуля:

module "vpc" {
  source     = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
  region     = "eu-west-1"
}

💡 Полезные практики:
- Держи модули в отдельном репозитории (или хотя бы папке)
- Дефолтные значения переменных — must-have
- Используй terraform-docs для автогенерации документации
- Добавляй README.md с примером вызова
- Всегда пиши outputs.tf — он пригодится для связи между модулями

🚨 Частые ошибки:
- Жестко закодированные значения (не делай так 🙅‍♂️)
- Отсутствие версионирования модулей
- Слишком "умные" модули (оставляй возможность переопределения)


🏁 Вывод:
Модули экономят время, упрощают сопровождение и помогают внедрять best practices по всей инфраструктуре. Один раз запилил модуль — используешь везде. Главное — не превращать модуль в монстра с сотней переменных.

📚 Полезное:
- Terraform Module Best Practices

#devops #terraform

Подпишись 👉@i_DevOps

23 апреля Магнит OMNI приглашает на Infrastructure MeetUp!

На этом мероприятии DevOps-инженеры, платформенные инженеры, системные администраторы и разработчики обсудят, как создать инфраструктуру, устойчивую к сбоям.

🔸В программе:
Доклады и дискуссии с участием специалистов из Магнит OMNI, Лаборатории Касперского, Авито, Cloud.ru и других компаний.

Спикеры расскажут про устройство инфраструктуры бизнес-сервисов и вспомогательных компонентов, обеспечение отказоустойчивости, развитие Observability в условиях распределенной инфраструктуры, а также использование протоколов, помогающих в нештатных ситуациях.

🔸Что будет?
— Разбор болей и кейсов, которые реально работают
— Розыгрыш призов (крутейший мерч!)
— Панельная дискуссия о том, как повышать устойчивость сервисов
— Живой нетворкинг

Митап пройдет в гибридном формате:
🔵Офлайн в московском офисе Магнита
🔵 Онлайн

🔸 23 апреля, в 17:30.
Не упустите возможность узнать новое и пообщаться с профессионалами!

Подробности и регистрация — по ссылке.

🆕 Bun Shell — кроссплатформенный shell прямо в JavaScript

Bun Shell — это встроенный интерпретатор shell-команд в Bun, позволяющий писать скрипты на JavaScript/TypeScript с лаконичным синтаксисом:

import { $ } from "bun";
await $`ls *.js`;

Основные возможности:
• Кроссплатформенность: работает на Windows, macOS и Linux.
• Поддержка переменных, редиректов, пайпов и шаблонов.
• Безопасность: автоматическое экранирование переменных.
• Взаимодействие с объектами JavaScript: Response, ArrayBuffer, Blob.
• Встроенные команды: cd, rm, echo и другие.

Пример использования с переменной:

const filename = "example.txt";
await $`cat ${filename}`;

https://bun.sh/blog/the-bun-shell

#devops #девопс

Подпишись 👉@i_DevOps

Виртуальные машины и контейнеры в одном окружении? Да, это реально! 

На вебинаре в среду расскажем и покажем, как виртуализация в экосистеме Deckhouse делает возможным запуск виртуальных машин рядом с контейнерами, обеспечивая единое, управляемое Kubernetes-окружение для построения современного частного облака. 

🗓 Дата: 23 апреля, среда
⏰ Время: 12:00 (МСК)
📌 Место: Онлайн, нужна регистрация

Обсудим:
🔹 какие возможности по управлению виртуальными машинами есть в Deckhouse;
🔹 для чего нужна совместная работа виртуальных машин и контейнеров;
🔹 какие сценарии виртуализации есть в экосистеме Deckhouse;
🔹 и главное — покажем тестовый стенд и приложение.

✍️ Участники вебинара смогут оставить заявку на тестирование Deckhouse Virtualization Platform или на запуск демоприложения в Deckhouse Kubernetes Platform.

Зарегистрироваться

Kubernetes в проде: 7 ошибок, которые совершают даже опытные

Если ты деплоишь сервисы в Kubernetes, скорее всего, ты уже наступал на эти грабли. А если нет — вот чеклист, чтобы не наступить.


1. Не включён livenessProbe и readinessProbe
Без этих пробы Kubernetes не понимает, когда перезапустить контейнер или исключить под из сервисов. В итоге — трафик идёт в мёртвые инстансы, а ты ловишь 500-е.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 10

2. resources.requests и limits не заданы
Если не выставить ресурсы, поды будут жрать всё подряд, а kube-scheduler может завалить ноды. Определи baseline и поставь лимиты с запасом:

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

3. Один replica на под в проде
Если у тебя только один реплика, ты не в HA. Любая перезагрузка = даунтайм. Минимум две — лучше три.

4. latest тег образа
image: myapp:latest — это лотерея. K8s не знает, что образ поменялся, и не перезапускает поды. Используй versioned теги (`v1.2.3`) или внедри CI, который автоматически делает новый тег и rollout.

5. Нет ограничений по PodDisruptionBudget
Без PDB можно случайно прибить все поды при drain'е ноды или апдейте. Добавь минимум 1 живой под:

minAvailable: 1

6. Логи в /var/log или вообще stdout игнорируется
Всё, что не идёт в stdout/stderr, теряется. Используй sidecar'ы или shipper'ы типа Fluent Bit, если хочешь нормальный логинг.

7. Секреты хранятся в plaintext в Git
Kubernetes Secret — это base64, а не шифрование. Либо используй sealed-secrets, либо интеграцию с HashiCorp Vault, SOPS или AWS KMS.


Вывод:
Даже базовые настройки могут сыграть злую шутку, если их игнорировать. Сделай себе шаблон Helm-чарта или Kustomize-паттерн, в котором всё это будет по умолчанию. И не забудь периодически пересматривать best practices — K8s развивается 🔄

#devops #девопс

Подпишись 👉@i_DevOps

🎯 Bash-совет дня: быстрое сравнение файлов по хэшу

Иногда нужно убедиться, что два файла идентичны. Вместо diff, который сравнивает содержимое построчно, проще сравнить их контрольные суммы.

Вот удобная однострочная команда:

[ "$(sha256sum file1 | awk '{print $1}')" = "$(sha256sum file2 | awk '{print $1}')" ] && echo "✅ Файлы одинаковые" || echo "❌ Файлы разные"

📌 Пояснение:
- sha256sum — создаёт SHA-256 хэш от файла.
- awk '{print $1}' — достаёт только сам хэш (без имени файла).
- [...] && ... || ... — условие в стиле bash: если хэши совпадают — выводим "файлы одинаковые", иначе — "разные".

🔥 Подходит для проверки резервных копий, дистрибутивов и любых бинарников.

👉@bash_srv

Wal-listener — это инструмент для прослушивания логов транзакций PostgreSQL (WAL) и конвертации их в удобный для обработки формат JSON.

Возможности

- Прослушивание изменений в PostgreSQL в режиме реального времени.
- Поддержка нескольких слотов репликации.
- Удобный вывод в формате JSON.
- Готов к использованию в качестве сервиса.

Пример использования

1. Создаём слот репликации:

   SELECT * FROM pg_create_logical_replication_slot('test_slot', 'wal2json');
   

2. Запускаем wal-listener:

   wal-listener --dsn "host=localhost port=5432 user=postgres dbname=test" --slot test_slot
   

3. Получаем JSON-объекты при изменениях в базе данных.

https://github.com/ihippik/wal-listener

#devops #девопс

Подпишись 👉@i_DevOps

Kubernetes: как не угробить прод с неправильными Liveness/Readiness пробыми 🧟‍♂️

Если ваши поды «умирают» слишком рано или слишком долго не проходят readiness — возможно, вы не до конца понимаете, как работают пробы в Kubernetes. А между тем, это критично для uptime и стабильности продакшена.


📌 Пробы — не «просто пинги»

- livenessProbe отвечает за "жив ли под". Если не проходит — kubelet убивает контейнер.
- readinessProbe — "готов ли под принимать трафик". Пока не готов — не пускается в сервис.

Неправильная настройка может привести к:
- бесконечным перезапускам (flapping),
- недоступности сервиса после деплоя,
- ненужной нагрузке на кластер.


🛠 Типичные ошибки

1. Тот же эндпоинт для обеих проб
Readiness может требовать больше инициализации. Разделяйте эндпоинты:
/healthz/live и /healthz/ready — хорошая практика.

2. Слишком агрессивные тайминги
initialDelaySeconds, timeoutSeconds, failureThreshold — не забывайте учитывать холодный старт (особенно при Java, .NET, DB init).

3. Тестирование только на dev/stage
На проде нагрузка выше, сеть может вести себя иначе. Профиль подов должен учитывать real-world сценарии.

4. Liveness вместо retries
Liveness не замена retry-логике в приложении. Используйте circuit breakers, retries и grace periods на уровне сервиса.


✅ Как делать правильно

- Используйте простые GET-запросы, без heavy логики.
- Не тестируйте зависимости (БД, внешние API) в liveness — пусть это останется за readiness.
- Применяйте terminationGracePeriodSeconds и preStop hook, чтобы избежать резкого отключения.


🧩 Стартовый шаблон для readiness/liveness

livenessProbe:
  httpGet:
    path: /healthz/live
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /healthz/ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 3

Вывод:
Настройка prob — это не ритуал ради YAML-а. Это инструмент стабильности и доступности. Подходите к ним осознанно, валидируйте на нагрузке и помните, что "здоровый" под ≠ "готовый к трафику".

#devops #девопс

Подпишись 👉@i_DevOps

16 главных DevOps-метрик (DORA и не только!) — на чем сосредоточиться и как использовать

DevOps‑метрики — это количественные показатели, которые позволяют оценить эффективность, производительность и общее состояние DevOps‑процессов. Они предлагают аналитический взгляд на конвейер поставки программного обеспечения, позволяя командам разработчиков выявлять проблемные места, повышать производительность и принимать решения на основе реальных данных.

В этой статье мы поговорим о важности мониторинга DevOps‑метрик и о том, что именно нужно отслеживать. От широко известных метрик, которые приобрели статус стандартных благодаря DORA (DevOps Research and Assessment), до других важных индикаторов — мы предлагаем вашему вниманию исчерпывающее руководство, которое поможет вам измерить и оптимизировать ваши DevOps‑практики.

https://spacelift.io/blog/devops-metrics

#devops #девопс

Подпишись 👉@i_DevOps