Bruno — это новый, современный и удобный инструмент для работы с API. В отличие от Postman и аналогов, Bruno хранит все данные локально в виде обычных файлов и папок, что позволяет легко версионировать их с помощью Git.
Основные особенности:
- Локальное хранение данных без облака
- Полная совместимость с Git
- Высокая производительность и минималистичный интерфейс
- Открытый исходный код
https://github.com/usebruno/bruno
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Основные особенности:
- Локальное хранение данных без облака
- Полная совместимость с Git
- Высокая производительность и минималистичный интерфейс
- Открытый исходный код
https://github.com/usebruno/bruno
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
🔥3👍2
CI/CD без боли: оптимизация пайплайнов на GitHub Actions 🚀
GitHub Actions — мощный инструмент, но без оптимизации ваш пайплайн легко превратится в тормозную мясорубку. Разбираемся, как выжать максимум из CI/CD на GitHub.
Почему это важно:
Быстрые и надёжные пайплайны — ключ к высокой скорости доставки. Медленные сборки = потеря времени, нервов и денег.
1. Кэшируй разумно
Используй
⚠️ Ключ должен быть завязан на lock-файлы, иначе можно словить конфликты версий.
2. Делай job-ы параллельными
Разделяй пайплайн на независимые шаги — unit-тесты, линтеры, сборка. Добавляй
3. Matrix strategy — must-have
Хочешь тестировать на разных версиях языка/ОС? Используй
Это масштабирует проверку без дублирования кода.
4. Отключи ненужные события
Не запускай воркфлоу на каждом чихе. Используй
Это поможет не перегружать runners.
5. Используй
Иногда надо протестить пайплайн руками — не бойся добавить ручной триггер:
6. Логи и таймауты — твои друзья
Добавляй
Вывод:
Грамотно настроенный GitHub Actions экономит время и снижает головную боль. Избегай монолитных пайплайнов, кэшируй умно и тестируй только то, что нужно. Автоматизация — это про контроль, а не хаос.
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
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 #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍4
🚨 Helm: как не сломать прод — 5 ошибок, которые делают все
Helm — must-have инструмент для деплоя в Kubernetes. Но даже опытные инженеры наступают на одни и те же грабли, особенно в проде. Разберём, какие ошибки чаще всего приводят к падениям и багам.
🔸 1.
Без
Решение: всегда используйте
🔸 2. Забытый
Нередко инженеры коммитят
Решение:
* Разделяй values по окружениям (
* Используй
* Применяй валидацию с helm-schema-gen
🔸 3. Не pinned зависимости в
Если чарты-зависимости подтягиваются без фиксации версий (
Решение:
Фиксируй зависимости чётко:
🔸 4. Отсутствие pre-upgrade и post-upgrade хуков
Если приложение требует миграций БД или прогрева кэша, а хуки не заданы — велика вероятность получить нерабочий релиз.
Решение:
Определи хуки в
🔸 5. Helm secrets хранятся в чистом виде в Git
Распакованный
Решение:
* Используй helm-secrets с
* Шифруй
✅ Вывод:
Helm — мощный, но не прощающий ошибок инструмент. Настрой atomic деплой, следи за values и зависимостями, автоматизируй pre/post-хуки и защищай секреты. Это минимальный чеклист для прод-готовности.
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Helm — must-have инструмент для деплоя в Kubernetes. Но даже опытные инженеры наступают на одни и те же грабли, особенно в проде. Разберём, какие ошибки чаще всего приводят к падениям и багам.
🔸 1.
helm upgrade без флага --atomicБез
--atomic Helm не откатывает релиз при ошибке — в кластере остаётся полусломанное состояние.Решение: всегда используйте
--atomic на проде:
helm upgrade my-app ./chart --atomic --install
🔸 2. Забытый
values.yaml с тестовыми значениямиНередко инженеры коммитят
values.yaml с включёнными debug-логами, выключенным HPA и отключённым SSL.Решение:
* Разделяй values по окружениям (
values-prod.yaml, values-staging.yaml)* Используй
.gitignore для временных файлов* Применяй валидацию с helm-schema-gen
🔸 3. Не pinned зависимости в
Chart.yamlЕсли чарты-зависимости подтягиваются без фиксации версий (
version: ^1.2.3), то обновления могут неожиданно всё сломать.Решение:
Фиксируй зависимости чётко:
version: 1.2.3 и контролируй обновления вручную.🔸 4. Отсутствие pre-upgrade и post-upgrade хуков
Если приложение требует миграций БД или прогрева кэша, а хуки не заданы — велика вероятность получить нерабочий релиз.
Решение:
Определи хуки в
templates/hooks.yaml:
apiVersion: batch/v1
kind: Job
metadata:
annotations:
"helm.sh/hook": pre-upgrade
🔸 5. Helm secrets хранятся в чистом виде в Git
Распакованный
secrets.yaml в Git — это инцидент.Решение:
* Используй helm-secrets с
sops* Шифруй
secrets.yaml и расшифровывай только при деплое:
helm secrets upgrade my-app -f secrets.enc.yaml
✅ Вывод:
Helm — мощный, но не прощающий ошибок инструмент. Настрой atomic деплой, следи за values и зависимостями, автоматизируй pre/post-хуки и защищай секреты. Это минимальный чеклист для прод-готовности.
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍3
Netshoot — набор инструментов для устранения сетевых проблем с Docker и Kubernetes.
Отладка сетей Docker и Kubernetes может быть сложной. Однако при правильном понимании принципов работы сетей Docker и Kubernetes, а также наличии подходящих инструментов, вы сможете эффективно выявлять и устранять сетевые проблемы. Контейнер netshoot включает в себя мощный набор инструментов для диагностики сетевых проблем в Docker. Вместе с этими инструментами идут практические примеры, демонстрирующие, как netshoot можно использовать в реальных сценариях.
https://github.com/nicolaka/netshoot
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Отладка сетей Docker и Kubernetes может быть сложной. Однако при правильном понимании принципов работы сетей Docker и Kubernetes, а также наличии подходящих инструментов, вы сможете эффективно выявлять и устранять сетевые проблемы. Контейнер netshoot включает в себя мощный набор инструментов для диагностики сетевых проблем в Docker. Вместе с этими инструментами идут практические примеры, демонстрирующие, как netshoot можно использовать в реальных сценариях.
https://github.com/nicolaka/netshoot
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍3
Crd-to-sample-yaml or cty ( city )
Утилита для генерации манифестов YAML из CRD.
Это простая утилита, написанная на Go, которая читает CRD-файлы и создает из них YAML-образцы.
Она использует
Установка:
Использование:
https://github.com/Skarlso/crd-to-sample-yaml
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Утилита для генерации манифестов YAML из CRD.
Это простая утилита, написанная на Go, которая читает CRD-файлы и создает из них YAML-образцы.
Она использует
controller-tools/pkg/crd/schema и controller-tools/pkg/crd/markers для интерпретации и разбора схемы.Установка:
go install github.com/Skarlso/crd-to-sample-yaml@latest
Использование:
crd-to-sample-yaml -path ./path/to/crds > output.yaml
https://github.com/Skarlso/crd-to-sample-yaml
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍2🔥1
💡 Как DevOps'у не утонуть в логах
Когда в продакшене случается затык, первое, что мы делаем - лезем в логи. Но с микросервисами, десятками подов и различными компонентами инфраструктуры, логов становится столько, что можно утонуть.
Вот несколько проверенных приёмов, которые реально спасают время:
🔹 Стандартизируй формат логов. JSON - твой друг. Структурированные логи можно парсить, фильтровать и индексировать.
🔹 Сразу думай про central logging. Loki + Grafana, Elasticsearch + Kibana или даже простой Fluent Bit + S3. Главное - не SSH на 20 серверов.
🔹 Добавляй trace_id во все логи. Это твой маяк в море. Особенно полезно, когда надо отслеживать один запрос через всю систему.
🔹 Фильтры, фильтры, фильтры. Хорошие правила фильтрации в Grafana или Kibana - это как хороший кофе с утра. Делают день лучше.
🔹 Логи - это не помойка. Не пиши туда
И напоследок: не забывай про ротацию и retention. Логи не должны жить вечно, особенно если ты не хочешь платить лишнее за storage.
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Когда в продакшене случается затык, первое, что мы делаем - лезем в логи. Но с микросервисами, десятками подов и различными компонентами инфраструктуры, логов становится столько, что можно утонуть.
Вот несколько проверенных приёмов, которые реально спасают время:
🔹 Стандартизируй формат логов. JSON - твой друг. Структурированные логи можно парсить, фильтровать и индексировать.
🔹 Сразу думай про central logging. Loki + Grafana, Elasticsearch + Kibana или даже простой Fluent Bit + S3. Главное - не SSH на 20 серверов.
🔹 Добавляй trace_id во все логи. Это твой маяк в море. Особенно полезно, когда надо отслеживать один запрос через всю систему.
🔹 Фильтры, фильтры, фильтры. Хорошие правила фильтрации в Grafana или Kibana - это как хороший кофе с утра. Делают день лучше.
🔹 Логи - это не помойка. Не пиши туда
print("Hello from service X"). Пиши полезное: ошибки, статусы, идентификаторы.И напоследок: не забывай про ротацию и retention. Логи не должны жить вечно, особенно если ты не хочешь платить лишнее за storage.
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
❤1👍1🔥1
🔧 Про grep, который умеет больше, чем ты думаешь
Все знают
📍 Ищем с контекстом
Хочешь не просто строку, а и то, что рядом?
Покажет 3 строки до и после найденной.
📍 Ищем по слову, а не по вхождению
Не хочешь ловить
Совпадение только по целому слову.
📍 Списки IP-шников? Без проблем.
Вытаскиваем IPv4 из текста:
📍 Ищем рекурсивно, но только в файлах
Искать по директории, пропуская бинарники и показывая имя файла:
📍 Цвет для глаз
Визуально быстрее цепляться за результат:
Если ты думаешь, что
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Все знают
grep как утилиту “найди мне это слово в этих логах”. Но давай копнём глубже — вот тебе пара трюков, которые удивят даже видавшего виды девопса:📍 Ищем с контекстом
Хочешь не просто строку, а и то, что рядом?
grep -C 3 "ошибка" /var/log/syslog
Покажет 3 строки до и после найденной.
📍 Ищем по слову, а не по вхождению
Не хочешь ловить
ошибка, если в логе есть предошибкака?
grep -w "ошибка" файл.log
Совпадение только по целому слову.
📍 Списки IP-шников? Без проблем.
Вытаскиваем IPv4 из текста:
grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' лог.txt
📍 Ищем рекурсивно, но только в файлах
Искать по директории, пропуская бинарники и показывая имя файла:
grep -rIn --exclude-dir={.git,node_modules} "TODO" .
📍 Цвет для глаз
Визуально быстрее цепляться за результат:
grep --color=auto "fail" журнал.log
Если ты думаешь, что
grep — это просто "найди слово", то, возможно, ты не используешь весь его потенциал. А зря 😉#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
🔥13❤2
Как проверить, что твои бэкапы не просто занимают место?
Резервное копирование — это как страховка: пока не случится беда, никто о нём не думает. Но когда приходит время восстановления, многие с удивлением обнаруживают, что бэкап либо повреждён, либо неполон, либо вовсе не содержит нужных данных. Как избежать этого?
🔹 Автоматическое тестирование восстановления
Настрой регулярное восстановление из резервных копий в тестовой среде. Например, можно развернуть временный сервер и поднять на нём восстановленную БД.
🔹 Сравнение контрольных сумм
Для файловых бэкапов сохраняй хэши (MD5, SHA256) до и после резервного копирования. Это поможет выявить изменения или повреждения данных.
🔹 Логирование и мониторинг
Настрой алерты на ошибки резервного копирования. Если скрипт завершился неудачно, ты должен об этом узнать раньше, чем твой прод улетит в тартарары.
🔹 Глубина хранения и дедупликация
Не удаляй старые бэкапы слишком рано. Иногда проблему замечают через несколько недель. Храни несколько версий резервных копий, но следи за размером и удостоверься, что не копируешь лишнее.
🔹 Периодические мануальные проверки
Раз в месяц пробуй восстановить данные вручную. Это займёт 15 минут, но может спасти компанию от потерь.
Бэкап, который не тестировали на восстановление — это просто набор битов. Убедись, что твои копии действительно можно использовать!
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Резервное копирование — это как страховка: пока не случится беда, никто о нём не думает. Но когда приходит время восстановления, многие с удивлением обнаруживают, что бэкап либо повреждён, либо неполон, либо вовсе не содержит нужных данных. Как избежать этого?
🔹 Автоматическое тестирование восстановления
Настрой регулярное восстановление из резервных копий в тестовой среде. Например, можно развернуть временный сервер и поднять на нём восстановленную БД.
🔹 Сравнение контрольных сумм
Для файловых бэкапов сохраняй хэши (MD5, SHA256) до и после резервного копирования. Это поможет выявить изменения или повреждения данных.
🔹 Логирование и мониторинг
Настрой алерты на ошибки резервного копирования. Если скрипт завершился неудачно, ты должен об этом узнать раньше, чем твой прод улетит в тартарары.
🔹 Глубина хранения и дедупликация
Не удаляй старые бэкапы слишком рано. Иногда проблему замечают через несколько недель. Храни несколько версий резервных копий, но следи за размером и удостоверься, что не копируешь лишнее.
🔹 Периодические мануальные проверки
Раз в месяц пробуй восстановить данные вручную. Это займёт 15 минут, но может спасти компанию от потерь.
Бэкап, который не тестировали на восстановление — это просто набор битов. Убедись, что твои копии действительно можно использовать!
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍6
🗂️ Как найти большие файлы в системе
Иногда на сервере внезапно заканчивается место, и нужно срочно найти, какие файлы занимают больше всего пространства. Вот простая команда на bash:
🔹 Что делает этот скрипт:
• Ищет все файлы больше 500 МБ по всему серверу.
• Показывает их размер и путь.
• Сортирует список по размеру - самые большие файлы будут вверху.
Совет:
Если нужно искать не по всему серверу, а только в домашней папке, просто поменяй
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Иногда на сервере внезапно заканчивается место, и нужно срочно найти, какие файлы занимают больше всего пространства. Вот простая команда на bash:
find / -type f -size +500M -exec ls -lh {} \; 2>/dev/null | awk '{ print $NF ": " $5 }' | sort -hr -k2
🔹 Что делает этот скрипт:
• Ищет все файлы больше 500 МБ по всему серверу.
• Показывает их размер и путь.
• Сортирует список по размеру - самые большие файлы будут вверху.
Совет:
Если нужно искать не по всему серверу, а только в домашней папке, просто поменяй
/ на ~/.#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍7
Docker на каждый день: Ключевые команды в одной статье-шпаргалке
Забудьте о том, что Docker — это некий таинственный инструмент исключительно для DevOps-инженеров. В современном мире разработки Docker стал таким же незаменимым швейцарским ножом, как Git или ваш любимый редактор кода. Он позволяет любому разработчику писать код, который будет одинаково работать на машине коллеги, на тестовом стенде и в продакшене, забыв о кошмаре "а у меня на машине все работает". Если вы еще не погрузились в мир контейнеризации или вам нужен удобный источник команд, эта статья — ваш экспресс-билет.
https://habr.com/ru/articles/913978/
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Забудьте о том, что Docker — это некий таинственный инструмент исключительно для DevOps-инженеров. В современном мире разработки Docker стал таким же незаменимым швейцарским ножом, как Git или ваш любимый редактор кода. Он позволяет любому разработчику писать код, который будет одинаково работать на машине коллеги, на тестовом стенде и в продакшене, забыв о кошмаре "а у меня на машине все работает". Если вы еще не погрузились в мир контейнеризации или вам нужен удобный источник команд, эта статья — ваш экспресс-билет.
https://habr.com/ru/articles/913978/
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
👍2🔥1
Tailspin - позволяет просматривать логи с подсветкой
Tailspin не делает предположений о формате или расположении элементов, которые нужно подсветить. По этой причине он не требует настройки, и подсветка будет работать одинаково стабильно для разных лог-файлов.
Особенности
🪵 Просмотр (или отслеживание) любых лог-файлов в любом формате
🍰 Не требует настройки или конфигурации
🌈 Подсвечивает числа, даты, IP-адреса, UUID, URL и многое другое
⚙️ Все группы подсветки настраиваемы
🧬 Легко интегрируется с другими командами
🔍 Использует less для прокрутки, поиска и фильтрации
https://github.com/bensadeh/tailspin
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Tailspin не делает предположений о формате или расположении элементов, которые нужно подсветить. По этой причине он не требует настройки, и подсветка будет работать одинаково стабильно для разных лог-файлов.
Особенности
🪵 Просмотр (или отслеживание) любых лог-файлов в любом формате
🍰 Не требует настройки или конфигурации
🌈 Подсвечивает числа, даты, IP-адреса, UUID, URL и многое другое
⚙️ Все группы подсветки настраиваемы
🧬 Легко интегрируется с другими командами
🔍 Использует less для прокрутки, поиска и фильтрации
https://github.com/bensadeh/tailspin
#devops #девопс
Подпишись 👉@i_DevOps
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2
HolmesGPT — опенсорсный DevOps-ассистент
Он соединяет AI-модели с данными мониторинга в реальном времени и организационными знаниями. Он использует агентный цикл для анализа данных из нескольких источников и выявления возможных первопричин.
Что может HolmesGPT?
👉 Расследует инциденты (AIOps) с помощью PagerDuty/OpsGenie/Prometheus/Jira
👉 Автоматизированная сортировка: отмечайте важные предупреждения и устанавливайте их приоритетность, чтобы ваша команда могла их рассмотреть
👉 Расширение возможностей оповещений: автоматическое добавление контекста к оповещениям, таким как журналы и информация о работоспособности микросервисов, для более быстрого поиска первопричин
👉 Выявляйте проблемы с облаком, задавая вопросы HolmesGPT о неработоспособности инфраструктуры
👉 Автоматизация Runbook простым языком: ускорьте решение известных проблем, проводя расследование в соответствии с предоставленными вами runbook.
https://github.com/robusta-dev/holmesgpt
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
Он соединяет AI-модели с данными мониторинга в реальном времени и организационными знаниями. Он использует агентный цикл для анализа данных из нескольких источников и выявления возможных первопричин.
Что может HolmesGPT?
👉 Расследует инциденты (AIOps) с помощью PagerDuty/OpsGenie/Prometheus/Jira
👉 Автоматизированная сортировка: отмечайте важные предупреждения и устанавливайте их приоритетность, чтобы ваша команда могла их рассмотреть
👉 Расширение возможностей оповещений: автоматическое добавление контекста к оповещениям, таким как журналы и информация о работоспособности микросервисов, для более быстрого поиска первопричин
👉 Выявляйте проблемы с облаком, задавая вопросы HolmesGPT о неработоспособности инфраструктуры
👉 Автоматизация Runbook простым языком: ускорьте решение известных проблем, проводя расследование в соответствии с предоставленными вами runbook.
https://github.com/robusta-dev/holmesgpt
#devops #девопс
Подпишись 👉@i_DevOps
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍2
🧵Понимание probes в Kubernetes
1/ Что такое probes в Kubernetes?
В Kubernetes probes используются для проверки состояния ваших контейнеров приложений.
Существует три типа:
* Liveness Probe (Проверка живости)
* Readiness Probe (Проверка готовности)
* Startup Probe (Проверка запуска)
Давайте разберёмся на аналогии с рестораном. 🧵👇
2/ Представьте ваше приложение как кухню в ресторане.
* Клиенты = Входящий трафик
* Шеф-повар = Контейнер приложения
* Официант = Kubernetes
Официанту (K8s) нужно понять:
* Жив ли шеф? (Liveness)
* Готов ли шеф принимать заказы? (Readiness)
* Завершил ли шеф подготовку? (Startup)
3/ 🍳 Liveness Probe = Жив ли шеф?
Эта проверка смотрит, функционирует ли кухня (приложение) вообще.
Если шеф теряет сознание или исчезает, официант (K8s) перезапустит кухню (контейнер).
4/ 🛎️ Readiness Probe = Готов ли шеф готовить?
Возможно, шеф проснулся, но ещё нарезает ингредиенты.
Пока шеф не готов, официант не должен принимать заказы (направлять трафик).
Если проверка не проходит, Kubernetes исключит под из балансировщика нагрузки.
5/ 🕐 Startup Probe = Завершил ли шеф настройку?
Некоторым шефам нужно больше времени, чтобы подготовиться.
Startup Probe даёт им дополнительное время перед началом остальных проверок.
Если эта проверка не проходит, K8s убьёт под, полагая, что он застрял. Полезно для медленно стартующих приложений!
6/ Итого 🧠
* Startup Probe: Приложение завершило запуск?
* Liveness Probe: Приложение всё ещё работает?
* Readiness Probe: Приложение готово обрабатывать трафик?
Используйте все три, чтобы сделать ваши развертывания в K8s максимально надёжными. 💪
#devops #девопс
📲 Мы в MAX
Подпишись 👉@i_DevOps
1/ Что такое probes в Kubernetes?
В Kubernetes probes используются для проверки состояния ваших контейнеров приложений.
Существует три типа:
* Liveness Probe (Проверка живости)
* Readiness Probe (Проверка готовности)
* Startup Probe (Проверка запуска)
Давайте разберёмся на аналогии с рестораном. 🧵👇
2/ Представьте ваше приложение как кухню в ресторане.
* Клиенты = Входящий трафик
* Шеф-повар = Контейнер приложения
* Официант = Kubernetes
Официанту (K8s) нужно понять:
* Жив ли шеф? (Liveness)
* Готов ли шеф принимать заказы? (Readiness)
* Завершил ли шеф подготовку? (Startup)
3/ 🍳 Liveness Probe = Жив ли шеф?
Эта проверка смотрит, функционирует ли кухня (приложение) вообще.
Если шеф теряет сознание или исчезает, официант (K8s) перезапустит кухню (контейнер).
4/ 🛎️ Readiness Probe = Готов ли шеф готовить?
Возможно, шеф проснулся, но ещё нарезает ингредиенты.
Пока шеф не готов, официант не должен принимать заказы (направлять трафик).
Если проверка не проходит, Kubernetes исключит под из балансировщика нагрузки.
5/ 🕐 Startup Probe = Завершил ли шеф настройку?
Некоторым шефам нужно больше времени, чтобы подготовиться.
Startup Probe даёт им дополнительное время перед началом остальных проверок.
Если эта проверка не проходит, K8s убьёт под, полагая, что он застрял. Полезно для медленно стартующих приложений!
6/ Итого 🧠
* Startup Probe: Приложение завершило запуск?
* Liveness Probe: Приложение всё ещё работает?
* Readiness Probe: Приложение готово обрабатывать трафик?
Используйте все три, чтобы сделать ваши развертывания в K8s максимально надёжными. 💪
#devops #девопс
Подпишись 👉@i_DevOps
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍2🔥1
⚡️⚡️Инциденты, метрики и спасенный прод на DevOops 2026
Даже самая отказоустойчивая инфраструктура иногда преподносит сюрпризы, а один неудачный коммит может устроить всей команде долгий вечер.
На DevOops 2026 будут разбирать, что делать с такими ситуациями в реальной инфраструктуре: от проблем с Kubernetes и GitOps до инцидентов, метрик и observability.
Программный комитет выбрал восемь докладов, которые рекомендует посмотреть в первую очередь.
Здесь — Kafka в Kubernetes, архитектура корпоративного GPT, GitOps без лишнего blast radius, security-политики, надежность, DORA и observability.
Все подробности — в карточках и на сайте.
🔥С промокодом
Купить билет
Даже самая отказоустойчивая инфраструктура иногда преподносит сюрпризы, а один неудачный коммит может устроить всей команде долгий вечер.
На DevOops 2026 будут разбирать, что делать с такими ситуациями в реальной инфраструктуре: от проблем с Kubernetes и GitOps до инцидентов, метрик и observability.
Программный комитет выбрал восемь докладов, которые рекомендует посмотреть в первую очередь.
Здесь — Kafka в Kubernetes, архитектура корпоративного GPT, GitOps без лишнего blast radius, security-политики, надежность, DORA и observability.
Все подробности — в карточках и на сайте.
🔥С промокодом
iDevOps персональные билеты дешевлеКупить билет
👍2👎1