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

🚀 Ускоряем CI/CD пайплайны на GitHub Actions: кеширование по-взрослому

CI тормозит? Пайплайн гоняет npm install по 5 минут? Пора серьёзно поговорить о кешировании в GitHub Actions.


GitHub Actions — мощный инструмент, но без кеша даже самый простой билд превращается в черепаху. Разберёмся, как грамотно использовать actions/cache, чтобы выжать максимум скорости.

🔧 Основы кеширования

GitHub предоставляет официальный экшен actions/cache, который позволяет сохранять каталоги между запусками воркфлоу. Ключевое понятие здесь — ключ кеша (cache key).

Пример:

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

Что тут происходит:
- path — папка, которую кешируем (`~/.npm`).
- key — уникальный ключ, зависящий от lock-файла.
- restore-keys — запасной вариант, если точного совпадения ключа нет.

⚡ Трюки для ускорения

1. Разделяй кеш по задачам. Не пихай всё в один архив. Кешируй отдельно npm, node_modules, dist/ — это гибко и эффективно.

2. Для Docker-образов — кешируй слои. Используй BuildKit и флаг --cache-to, --cache-from. Пример:

- name: Build Docker image
  run: |
    docker buildx build \
      --cache-from=type=gha \
      --cache-to=type=gha,mode=max \
      -t my-app .

3. Осторожно с ключами. Часто меняющийся ключ = каждый раз новый кеш = медленно. Сделай разумный баланс между стабильностью и свежестью.

4. Тестируй локально. Используй act, чтобы отлаживать воркфлоу на локалке — сэкономишь время и нервы.


✅ Вывод

Кеш в GitHub Actions — не волшебная пуля, но при правильной настройке он может сократить время CI в разы. Следи за размером кеша, обновляй ключи с умом и профилируй пайплайн. И не забывай: кеш — твой друг, пока ты его контролируешь.

#devops #девопс

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

💡 McFly — это улучшенная история командной строки с возможностями поиска на основе временной оси, контекста и машинного обучения.

McFly заменяет стандартную историю bash с возможностью быстрого поиска по истории команд с учётом контекста текущего каталога, времени и других факторов. Он написан на Rust и работает в терминале с поддержкой fzf-подобного интерфейса.

🔧 Поддерживает:
- Bash
- Zsh
- Fish

📦 Возможности:
- Умный поиск по истории команд.
- Учёт текущего каталога и других факторов.
- Простое подключение к вашему shell.

📚 Установка:
Доступен через Homebrew, AUR, Nix и другие.

https://github.com/cantino/mcfly

#devops #девопс

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

🚀 Подборка Telegram каналов для программистов

Системное администрирование, DevOps 📌

https://news.1rj.ru/str/bash_srv Bash Советы
https://news.1rj.ru/str/win_sysadmin Системный Администратор Windows
https://news.1rj.ru/str/sysadmin_girl Девочка Сисадмин
https://news.1rj.ru/str/srv_admin_linux Админские угодья
https://news.1rj.ru/str/linux_srv Типичный Сисадмин
https://news.1rj.ru/str/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
https://news.1rj.ru/str/linux_odmin Linux: Системный администратор
https://news.1rj.ru/str/devops_star DevOps Star (Звезда Девопса)
https://news.1rj.ru/str/i_linux Системный администратор
https://news.1rj.ru/str/linuxchmod Linux
https://news.1rj.ru/str/sys_adminos Системный Администратор
https://news.1rj.ru/str/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
https://news.1rj.ru/str/sysadminof Книги для админов, полезные материалы
https://news.1rj.ru/str/i_odmin Все для системного администратора
https://news.1rj.ru/str/i_odmin_book Библиотека Системного Администратора
https://news.1rj.ru/str/i_odmin_chat Чат системных администраторов
https://news.1rj.ru/str/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
https://news.1rj.ru/str/sysadminoff Новости Линукс Linux

1C разработка 📌
https://news.1rj.ru/str/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://news.1rj.ru/str/DevLab1C 1С:Предприятие 8
https://news.1rj.ru/str/razrab_1C 1C Разработчик
https://news.1rj.ru/str/buh1C_prog 1C Программист | Бухгалтерия и Учёт
https://news.1rj.ru/str/rabota1C_rus Вакансии для программистов 1С

Программирование C++📌
https://news.1rj.ru/str/cpp_lib Библиотека C/C++ разработчика
https://news.1rj.ru/str/cpp_knigi Книги для программистов C/C++
https://news.1rj.ru/str/cpp_geek Учим C/C++ на примерах

Программирование Python 📌
https://news.1rj.ru/str/pythonofff Python академия.
https://news.1rj.ru/str/BookPython Библиотека Python разработчика
https://news.1rj.ru/str/python_real Python подборки на русском и английском
https://news.1rj.ru/str/python_360 Книги по Python

Java разработка 📌
https://news.1rj.ru/str/BookJava Библиотека Java разработчика
https://news.1rj.ru/str/java_360 Книги по Java Rus
https://news.1rj.ru/str/java_geek Учим Java на примерах

GitHub Сообщество 📌
https://news.1rj.ru/str/Githublib Интересное из GitHub

Базы данных (Data Base) 📌
https://news.1rj.ru/str/database_info Все про базы данных

Мобильная разработка: iOS, Android 📌
https://news.1rj.ru/str/developer_mobila Мобильная разработка
https://news.1rj.ru/str/kotlin_lib Подборки полезного материала по Kotlin

Фронтенд разработка 📌
https://news.1rj.ru/str/frontend_1 Подборки для frontend разработчиков
https://news.1rj.ru/str/frontend_sovet Frontend советы, примеры и практика!
https://news.1rj.ru/str/React_lib Подборки по React js и все что с ним связано

Разработка игр 📌
https://news.1rj.ru/str/game_devv Все о разработке игр

Библиотеки 📌
https://news.1rj.ru/str/book_for_dev Книги для программистов Rus
https://news.1rj.ru/str/programmist_of Книги по программированию
https://news.1rj.ru/str/proglb Библиотека программиста
https://news.1rj.ru/str/bfbook Книги для программистов

БигДата, машинное обучение 📌
https://news.1rj.ru/str/bigdata_1 Big Data, Machine Learning

Программирование 📌
https://news.1rj.ru/str/bookflow Лекции, видеоуроки, доклады с IT конференций
https://news.1rj.ru/str/rust_lib Полезный контент по программированию на Rust
https://news.1rj.ru/str/golang_lib Библиотека Go (Golang) разработчика
https://news.1rj.ru/str/itmozg Программисты, дизайнеры, новости из мира IT
https://news.1rj.ru/str/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻
https://news.1rj.ru/str/nodejs_lib Подборки по Node js и все что с ним связано
https://news.1rj.ru/str/ruby_lib Библиотека Ruby программиста
https://news.1rj.ru/str/lifeproger Жизнь программиста. Авторский канал.

QA, тестирование 📌
https://news.1rj.ru/str/testlab_qa Библиотека тестировщика

Шутки программистов 📌
https://news.1rj.ru/str/itumor Шутки программистов

Защита, взлом, безопасность 📌
https://news.1rj.ru/str/thehaking Канал о кибербезопасности
https://news.1rj.ru/str/xakep_2 Хакер Free

Книги, статьи для дизайнеров 📌
https://news.1rj.ru/str/ux_web Статьи, книги для дизайнеров

Математика 📌
https://news.1rj.ru/str/Pomatematike Канал по математике
https://news.1rj.ru/str/phis_mat Обучающие видео, книги по Физике и Математике
https://news.1rj.ru/str/matgeoru Математика | Геометрия | Логика

Excel лайфхак📌
https://news.1rj.ru/str/Excel_lifehack

https://news.1rj.ru/str/mir_teh Мир технологий (Technology World)

Вакансии 📌
https://news.1rj.ru/str/sysadmin_rabota Системный Администратор
https://news.1rj.ru/str/progjob Вакансии в IT

Трюки для ускорения Docker-образов на проде

Контейнеры — сердце современных приложений. Но тяжёлые образы = медленные деплои и высокие затраты. Как ускорить образы без боли?

Мультистейдж билды — must have

Используй multi-stage builds, чтобы собрать приложение в одном контейнере, а продакшн-образ сделать минимальным:

# Сборка
FROM golang:1.22 as builder
WORKDIR /app
COPY . .
RUN go build -o app

# Продакшн
FROM alpine:latest
WORKDIR /app
COPY --from=builder /app/app .
CMD ["./app"]

Минимизируй базовые образы

Выбирай облегчённые базовые образы:
• alpine вместо ubuntu
• distroless для максимальной безопасности и минимального веса

Оптимизируй порядок слоёв

Чем выше изменяемость — тем ниже слой:
• Сначала COPY go.mod, npm package.json, установка зависимостей
• Потом COPY . . с кодом проекта

Это позволяет кэшировать большую часть слоёв даже при частых изменениях кода.

Чисть за собой

Всегда удаляй временные файлы и зависимости для сборки:

RUN apt-get install -y build-essential && \
make build && \
apt-get remove --purge -y build-essential && \
apt-get autoremove -y && \
apt-get clean

Сжимай образы

Используй docker-slim — он автоматически оптимизирует образ, удаляя всё ненужное:

docker-slim build --http-probe my-app:latest



Как применять и чего избегать
• В продакшне старайся держать образы <100MB
• Не добавляй лишние пакеты “на всякий случай”
• Проверяй образы на уязвимости: trivy image your-app:tag

#devops #девопс

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

Bruno — это новый, современный и удобный инструмент для работы с API. В отличие от Postman и аналогов, Bruno хранит все данные локально в виде обычных файлов и папок, что позволяет легко версионировать их с помощью Git.

Основные особенности:
- Локальное хранение данных без облака
- Полная совместимость с Git
- Высокая производительность и минималистичный интерфейс
- Открытый исходный код

https://github.com/usebruno/bruno

#devops #девопс

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

Работа с хранилищами в Kubernetes: руководство для инженеров

Как DevOps-инженер я часто сталкиваюсь с необходимостью глубокого понимания тонких аспектов Kubernetes. Одним из таких ключевых элементов является управление хранилищем данных. Хотя этот элемент иногда остаётся в тени других задач, его важность для успешного развёртывания и поддержки приложений велика.

Накопленный мною опыт в этой области стал основой для этой статьи.

Я сфокусируюсь на трёх ключевых элементах управления хранилищем в Kubernetes:

PersistentVolumes (PV).
PersistentVolumeClaims (PVC).
Storage Classes.

https://habr.com/ru/companies/T1Holding/articles/781368/

#devops #девопс

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

Вы CTO или хотите им стать?
Управление качеством — это не просто исправление ошибок. Это предотвращение проблем до их появления. На нашем бесплатном вебинаре мы расскажем, как именно CTO может проактивно управлять качеством в своих проектах и минимизировать риски.

🔑 Что узнаете на вебинаре:
· Как выявлять риски до внедрения, а не после провала
· Инструменты превентивного анализа: тест-дизайн, Code Review, метрики и автоматизация
· Почему ответственность за качество лежит не только на тестировщиках, а на всей команде

🚀 Кому будет полезно: CTO, руководителям разработки, QA-лидам и тех-менеджерам, которые хотят выстроить эффективную систему контроля качества и избежать ошибок на ранних этапах.

🎓 Понравится вебинар - приходите на курс «CTO / Технический директор» со скидкой по промокоду BIRDS_CTO.

🔗 Зарегистрироваться на вебинар: https://vk.cc/cLofpK

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

CI/CD без боли: оптимизация пайплайнов на GitHub Actions 🚀

GitHub Actions — мощный инструмент, но без оптимизации ваш пайплайн легко превратится в тормозную мясорубку. Разбираемся, как выжать максимум из CI/CD на GitHub.


Почему это важно:
Быстрые и надёжные пайплайны — ключ к высокой скорости доставки. Медленные сборки = потеря времени, нервов и денег.


1. Кэшируй разумно
Используй actions/cache для ускорения зависимостей, но не кэшируй всё подряд. Пример для Node.js:

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

⚠️ Ключ должен быть завязан на lock-файлы, иначе можно словить конфликты версий.


2. Делай job-ы параллельными
Разделяй пайплайн на независимые шаги — unit-тесты, линтеры, сборка. Добавляй needs: там, где реально нужно, а не везде.


3. Matrix strategy — must-have
Хочешь тестировать на разных версиях языка/ОС? Используй matrix:

strategy:
  matrix:
    node-version: [16, 18, 20]

Это масштабирует проверку без дублирования кода.


4. Отключи ненужные события
Не запускай воркфлоу на каждом чихе. Используй on: грамотно:

on:
  push:
    branches:
      - main
  pull_request:
    paths:
      - 'src/**'

Это поможет не перегружать runners.


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

on:
  workflow_dispatch:

6. Логи и таймауты — твои друзья
Добавляй timeout-minutes к job-ам и выводи ключевые логи через ::group:: и ::endgroup::, чтобы не утонуть в консоли.


Вывод:
Грамотно настроенный GitHub Actions экономит время и снижает головную боль. Избегай монолитных пайплайнов, кэшируй умно и тестируй только то, что нужно. Автоматизация — это про контроль, а не хаос.


#devops #девопс

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