Библиотека девопса | DevOps, SRE, Sysadmin
Открыть в Telegram
1 272
Подписчики
Нет данных24 часа
+17 дней
+230 дней
Архив постов
Облако ITENTIS CLOUD: технологии топов, цена без наценки (и живая поддержка!)
Нашли брендовую вещь в надежном маркете на 30% дешевле? Вот и мы так же. 😉
ITENTIS CLOUD — не "бюджетный" вариант. Это ВСЕ те же технологии, что у Яндекса, Mail или VK (VPC, Kubernetes, S3, снимки, автомасштабирование), но...
🔥 ...ЗНАЧИТЕЛЬНО ДЕШЕВЛЕ! 🔥
Зачем платить за бренд? Получите то же самое (а кое-что лучше) и сэкономьте. Не верите? Сравните тарифы! Надежные дата-центры Tier III, как у всех.
И главное — наша поддержка. Вот где мы их РЕАЛЬНО обходим:
💩 У них: очереди, боты, ответ "в течение 24 часов".
😍 У нас: живой, компетентный специалист 24/7. Не бот! Настоящий человек, который РАЗБЕРЕТСЯ. Ответ за минуты. Сложный Kubernetes? Объясним и поможем. Это наш стандарт.
Что вы получаете за меньшие деньги:
1. Та же "начинка": все ключевые технологии (VPC, Kubernetes, S3 и т.д.) — как у топов.
2. Надежность: Tier III, 2FA, шифрование, брандмауэры.
3. Скорость: запуск кластера быстрее доставки пиццы.
4. Простой контроль: интуитивное управление.
5. ГЛАВНОЕ: цена, от которой улыбнетесь + поддержка, которая реально спасает.
"А подвох?" Да нигде!
▶️14 дней БЕСПЛАТНО: протестируйте всё.
▶️БЕСПЛАТНАЯ миграция: перенесем ваши проекты без простоев.
▶️Гарантия возврата: риск — ноль.
‼️ Понравится? Расскажите друзьям! Реферальная программа: за каждого клиента — бонус или скидка. Без мишуры.
Итог: ITENTIS CLOUD = Технологии топов + Честная цена + Человеческая поддержка 24/7.
Хватит переплачивать и ждать ответа! Получите максимум.
👉 Действуйте выгодно:
1. Сравните тарифы: https://itentis.cloud
2. Пишите:
🤖 Telegram-бот: @itentis_bot (Фраза: "Хочу облако дешевле Яндекса!")
✉️ Почта: sales@itentis.ru
3. Скажите: "Читал пост про ЭКОНОМИЮ в облаке!" 🚀(Получите бонус!)
4. Присоединяйтесь: https://t.me/+D0MuFDf8P1FlMTJi
https://itentis.ru Мощное облако. Честная цена. Люди на связи.
Реклама. ООО "АВАНГАРД", ОГРН 1107746046550, erid: 2VtzqxcZdhf
💡 Сегодня немного про боль Kubernetes-кластеров
Когда у тебя всё крутится в k8s, кажется - удобно: автоскейлинг, изоляция, сервисы живут своей жизнью. Но как только в кластере начинают появляться десятки namespace и сотни подов, без нормальной политики ресурсов всё превращается в хаос.
👉 У каждого пода должны быть
requests и limits. Если этого нет - кластер живёт как коммуналка без счётчиков: кто успел, тот и съел. Один жадный контейнер может легко задушить соседей.
👉 Мониторинг на уровне ResourceQuota и LimitRange реально спасает от «сюрпризов» в проде.
👉 А ещё - включите PodPriority и Preemption. Это даёт возможность критичным сервисам выжить, даже если какой-то non-prod под начал жрать всю память.
В итоге Kubernetes сам по себе не магия. Это инструмент. А инструмент требует гигиены и правил.
Подпишись 👉@devopslib🚨 Скрытые расходы старого CI/CD
Очень часто вижу, что команды годами используют один и тот же CI/CD, который когда-то «поставили и забыли». На первый взгляд всё работает: пайплайны крутятся, артефакты собираются. Но внутри копятся скрытые издержки:
🐌 Медленные билды - ожидание деплоя в 10–15 минут превращается в десятки потерянных часов в месяц.
💸 Железо и лицензии - старые агенты гоняются на жирных VM, которые никто не оптимизировал.
🤯 Сложность поддержки — только один человек знает, как там всё устроено. Уйдёт - полкоманды будет гадать, что за магия в YAML.
🔒 Безопасность - забытые токены, старые версии раннеров, отсутствие актуальных патчей.
👉 В итоге мы «платим налог» не деньгами напрямую, а временем и рисками.
Что можно сделать:
1. Поставить метрики времени сборок и деплоя - пусть будет видно реальные цифры.
2. Разобрать пайплайны: есть ли шаги, которые можно параллелить или кэшировать.
3. Проверить обновления агента/раннера. Иногда апгрейд даёт +50% к скорости.
4. Автоматизировать инфраструктуру CI/CD через код (Terraform, Ansible, Helm) - чтобы не зависеть от «человека-ключа».
CI/CD - это не просто труба для кодека, а живой сервис. И его тоже надо мониторить и оптимизировать.
Подпишись 👉@devopslib
MTC Engineer Hack — хакатон на стыке инженерии и ИТ от МТС. Реши технический кейс онлайн и получи приглашение на финал в Москве, где сможешь познакомиться с экспертами МТС. Призовой фонд — 500 000 рублей.
🗓 Регистрация: https://cnrlink.com/mtsengineerhacklibsre
Приглашаем студентов и молодых инженеров в областях сетевых технологий, DevOps, аппаратной разработки, радиоинженерии.
Ты сможешь:
🔺 Решить кейсы, основанные на реальной работе инженеров МТС: от проектирования до оптимизации сетей.
🔺 Показать экспертам свои решения и получить обратную связь.
🔺 Попрактиковаться на задачах, которые позволят почувствовать себя частью технологической команды МТС.
🔺 Принять участие в финале в Москве. Билеты и проживание оплатят организаторы.
C 3 по 5 октября пройдёт онлайн-этап: участники готовят кейс по своему профилю. 11 октября — финал, где эксперты компании помогут разобраться в деталях и дадут советы по доработке решений, а ты сможешь выиграть мерч и принять участие в Tech Corner с Arduino и роботами.
Регистрация до 1 октября на Codenrock: https://cnrlink.com/mtsengineerhacklibsre
🚀 Как DevOps-инженеры мы часто увязаем в задачах автоматизации и забываем про «гигиену» инфраструктуры. А ведь простые проверки могут спасать от неприятных ночных алертов:
🔎 Периодически проверяй лимиты и квоты в облаке. Упёрся в лимит IP-адресов или дисков - и вот у тебя прод простаивает.
🧹 Смотри на orphan-ресурсы — старые volume, неиспользуемые load balancer’ы, забытые секреты в Vault. Всё это стоит денег и иногда может мешать.
🕓 Планируй регулярный audit logs review. Лишние сервисные аккаунты или подозрительная активность легко пропустить, если смотреть только на дашборды.
🛡 Не хардкодь секреты. Даже тестовые ключи лучше сразу класть в менеджер секретов, чтобы не ловить «утечку века» из git.
Внедрив маленькие привычки, можно сократить 80% неожиданных проблем и освободить время на то, что реально интересно.
Подпишись 👉@devopslib
💡 Многие девопсы недооценивают силу readiness и liveness проб в Kubernetes.
Проблема: без них kubelet считает под «живым», даже если приложение давно висит и не отвечает. В итоге у тебя в кластере «зелёные» поды, а пользователи шлют мат в поддержку.
👉 Разница:
LivenessProbe — проверяет, живо ли приложение. Если не отвечает - pod рестартует.
ReadinessProbe — проверяет, готов ли сервис обрабатывать трафик. Если нет - трафик не идёт, но pod не перезапускается.
⚙️ Частые ошибки:
- Делают одинаковый endpoint для обоих проб. В итоге под либо вечно рестартует, либо никогда не попадает в сервис.
- Ставят слишком жёсткие таймауты - приложение ещё грузит кэш, а kubelet уже думает «оно мёртвое».
- Забывают про
startupProbe - и получают вечный рестарт на тяжёлых приложениях (например, Java с долгим стартом).
✅ Хорошая практика:
- liveness → простой healthcheck (например, GET /ping).
- readiness → что-то посложнее (например, проверка подключения к БД).
- startupProbe → обязательно для всего, что стартует дольше пары секунд.
Kubernetes умеет заботиться о твоих подах, но только если ты правильно объяснишь ему, что значит «жив» и «готов».
Подпишись 👉@devopslib🔥 kubectl rollout restart - лучший друг девопса
Когда нужно быстро перезапустить деплоймент в Kubernetes, многие лезут редактировать манифест или руками удаляют поды. Но есть куда более элегантный способ:
kubectl rollout restart deployment my-app
replicaSet с теми же образами.
- Аккуратно перезапускает поды по rolling update.
⚡️ Плюсы:
- Удобно для обновления конфигов (например, ConfigMap или Secret), если они примонтированы в поды.
- Можно применить массово:
kubectl rollout restart deployment -n my-namespace
daemonset / statefulset.
💡 Если хочешь проверить статус перезапуска:
kubectl rollout status deployment my-app
🚀 Как я однажды сломал прод одним
kubectl apply
Сидишь себе спокойно, делаешь хотфикс, вроде всё готово. Думаю: "ну ща быстренько закатим" → kubectl apply -f deployment.yaml.
И тут - бах! Вылетает вся продовая нагрузка.
Почему?
А потому что в deployment.yaml был replicas: 1, а в кластере реально крутилось 12 подов. 😅
Kubernetes честно решил: "Ну раз надо 1, значит уберём остальные".
И убрал.
⚡️Вывод:
- Никогда не храните в гите "локальные" конфиги без проверки.
- Сравнивайте diff перед применением (kubectl diff -f ...).
- Лучше юзать GitOps (ArgoCD / Flux), чтобы руками не катать.
Теперь у нас правило: в прод руками через kubectl apply - нельзя. Только через пайплайны.
Подпишись 👉@devopslibGitHub Actions: секреты без боли и утечек
Вот концентрат практик, чтобы ваши токены и ключи не вываливались в логи и чужие форки.
🔐 Где хранить
-
Secrets: шифруются, доступны через secrets.*. Уровни: Repository, Environment, Organization, Dependabot.
- Variables (vars): не для чувствительного — просто конфиг.
- Environment + reviewers: ставьте для production - без апрува шаги с секретами не стартуют.
🪪 GITHUB_TOKEN и права
Явно задавайте права минимально необходимые:
permissions:
contents: read
id-token: write # нужно для OIDC
jobs:
deploy:
permissions:
id-token: write
contents: read
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: AWS OIDC
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
aws-region: eu-central-1
- run: aws sts get-caller-identity
pull_request из форков - и это хорошо.
Если нужно выполнить деплой/проверку после мерджа - делайте через workflow_run или отделяйте джобы:
if: github.event.pull_request.head.repo.fork == false
pull_request_target для запуска непроверенного кода с секретами.
🧯 Не печатайте секреты
- Никогда не echo $SECRET.
- Прокидывайте через stdin:
echo "${{ secrets.NPM_TOKEN }}" | npm login --registry=https://registry.npmjs.org --scope=@org --auth-type=legacy --password-stdin
echo "::add-mask::${TOKEN_FROM_API}"
set -x/trace в шагах, где работают секреты.
🗝️ Секрет как файл
- name: Write SSH key
run: |
install -m 700 -d ~/.ssh
printf '%s' "${{ secrets.DEPLOY_KEY }}" > ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
gh secret set NPM_TOKEN --repo owner/repo --body "$TOKEN"
gh secret set PROD_DB_URL --env production --repo owner/repo --body "$URL"
name: deploy
on:
push:
branches: [ main ]
jobs:
deploy:
environment: production # защита + секреты проды
permissions:
contents: read
id-token: write
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Login registry
run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
- name: Cloud auth (OIDC)
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
aws-region: eu-central-1
- name: Deploy
run: ./scripts/deploy.sh
environment, никакого echo, форки изолируем, сканирование включаем, ротацию автоматизируем.
Подпишись 👉@devopslib🔥 GitHub Actions и секреты: как не словить утечку
Многие думают, что положить секреты в Secrets в настройках репозитория - это всё, можно расслабиться. Но есть нюансы:
1️⃣ Secrets = env vars
В рантайме GitHub Actions подставляет секреты как переменные окружения. Их легко случайно вывести в лог, если бездумно делать
echo $SECRET_KEY. Логи сохраняются, а доступ к ним могут получить коллеги с правами на Actions.
2️⃣ Маскирование работает не всегда
GitHub пытается автоматически маскировать значения секретов в логах. Но если у тебя секрет - это, например, base64 строка или JSON, маскировка может сработать криво. Тут уже сам контролируешь вывод.
3️⃣ Не храни много секретов в репозитории
Лучше использовать GitHub OIDC (OpenID Connect) и получать временные креды от AWS, GCP или Azure прямо в рантайме. Так ты избежишь постоянных ключей в Secrets.
4️⃣ Используй environments
В GitHub есть Environments с отдельными секретами и правилами доступа. Можно разграничить staging/prod, включить approvals перед деплоем. Это must-have.
5️⃣ Проверяй permissions у Actions
По умолчанию GitHub даёт job полный доступ к GITHUB_TOKEN. Иногда достаточно permissions: read-only, а не write-all. Меньше прав → меньше дыр.
💡Для управления секретами в масштабах компании лучше интегрировать GitHub с HashiCorp Vault, Doppler или AWS Secrets Manager. Тогда GitHub Secrets будет только точкой входа, а не хранилищем всего подряд.
Подпишись 👉@devopslib
🔥 Открытый урок «Архитектура развертывания GitLab: от тестовой среды до продакшна».
🗓 10 сентября в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «CI/CD на основе GitLab».
🎯 На вебинаре разберем:
✔️ Как выбрать способ развертывания GitLab: Omnibus, Docker, Kubernetes
✔️ Рекомендации по архитектуре для разных масштабов: от одиночного сервера до распределённой инсталляции
✔️ Сравнение плюсов и минусов подходов: простота, отказоустойчивость, масштабируемость
✔️ Типичные проблемы при развёртывании и как их избежать
👥 Кому будет интересно:
- Начинающим DevOps-инженерам — вы получите базовое понимание архитектуры GitLab и научитесь разворачивать его под разные задачи
- DevOps-практикам, которые уже используют GitLab и хотят повысить стабильность и отказоустойчивость
- Инженерам по внедрению CI/CD, которым важно понять, как масштабировать GitLab в корпоративной среде
🎯 Что вы получите:
- Понимание, как развернуть GitLab оптимально под свои задачи
- Понимание, как правильно выбрать среду (Docker vs Kubernetes) для развёртывания
- Практические советы по стабильности, резервированию и отказоустойчивости GitLab-инсталляций
🔗 Ссылка на регистрацию: https://vk.cc/cPbf0Q
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🛠️ GitHub Actions: секреты и подводные камни
GitHub Actions сегодня используют все - от пет-проектов до продакшн пайплайнов. Но даже у опытных инженеров часто встречаются ошибки при работе с секретами.
❌ Типичные ошибки:
- Хранение токенов в коде или
.env файлах, которые случайно попадают в репозиторий.
- Вывод секретов в логи (например, через echo). GitHub заменяет их на ***, но иногда этого недостаточно.
- Использование одного общего токена для разных окружений (dev, staging, prod).
✅ Лучшие практики:
1. Secrets vs. Environments
Используй Environments с разными наборами секретов для разных стадий. Например: STAGING_DB_PASS и PROD_DB_PASS.
2. OIDC вместо токенов
GitHub поддерживает OIDC Federation. Это значит, что пайплайн может получать временные креды от AWS, GCP или Azure без хранения ключей.
3. Проверяй разрешения по умолчанию
В permissions: указывай минимально необходимые. Например:
permissions:
contents: read
id-token: write
secret scanning и push protection, чтобы случайно не залить ключи.
💡 Маленький трюк:
Если нужно временно отладить пайплайн с секретом - лучше использовать ::add-mask:: в логах, чем echo.
Подпишись 👉@devopslib🔥 GitOps - next level для DevOps
Раньше деплой выглядел так: написали Helm-чарт → закинули
kubectl apply → надеемся, что всё взлетит. Но у такого подхода куча минусов: ручные действия, нет прозрачного аудита, легко ошибиться.
🛠 Решение - GitOps.
👉 Суть: всё, что крутится в кластере, описано в Git.
- Изменения вносим через Pull Request.
- CI прогоняет проверки.
- Спец-оператор (ArgoCD или Flux) синхронизирует кластер с Git-репозиторием.
📌 Преимущества:
- Истина всегда в Git → легко откатиться.
- Аудит и история изменений из коробки.
- Меньше доступа к самому кластеру → безопаснее.
- Автоматическая самовосстановляемость: если кто-то руками изменит деплой, GitOps всё вернёт.
💡 По сути, Git становится "центральным управлением инфраструктуры".
Если раньше у вас был ssh и kubectl, то теперь всё решает git push.
❓А у вас уже есть GitOps в проде или пока классические пайплайны?
Подпишись 👉@devopslib🔥 CI/CD пайплайны: боль или спасение?
Любой DevOps рано или поздно сталкивается с тем, что пайплайн превращается в монстра: шаги на 2000 строк, десятки if-ов, и полдня на разбор «почему не задеплоилось».
Но по сути CI/CD - это не только «запустить тесты и выкатить в прод», а целая философия:
🔹 CI (Continuous Integration)
- каждое изменение мержится быстро и проверяется автоматически;
- цель - держать main-ветку в «рабочем» состоянии всегда;
- меньше конфликтов и сюрпризов при релизах.
🔹 CD (Continuous Delivery/Deployment)
- всё, что прошло CI, можно выкатывать хоть в прод;
- ручная кнопка или автодеплой — зависит от зрелости команды;
- уменьшает время «от коммита до продакшна».
⚡️ Где ломается магия?
- Если пайплайны начинают жить своей жизнью, а разработчики боятся их трогать.
- Если тесты гоняются по часу, и команда снова жмёт «на выходных зарелизим».
- Если нет нормальной стратегии отката.
💡 Совет: держи пайплайн простым, модульным и прозрачным. Лучше несколько коротких пайплайнов, чем один гигант.
А у тебя пайплайн больше похож на швейцарские часы или на «дженкинс на костылях»? 😅
Подпишись 👉@devopslib
🇷🇺 100% российская разработка
INFRAX — платформа all-in-one для управления ИТ-инфраструктурой:
✅ Мониторинг инфраструктуры (ITOM)
✅ Удаленный доступ для сотрудников и привилегированных пользователей
✅ Обработка заявок пользователей (ServiceDesk)
✅ База знаний с разграничением доступа к категориям (публичные и закрытые)
✅ Автоматизация (скрипты и планировщик)
✅ Контроль привилегированных пользователей. Видеозапись сессий RDP/SSH/VNC. (PAM)
✅ Управление доступами. Доступ ко всем корпоративным сервисам через одну учетку (IAM)
БЕСПЛАТНО до 100 пользователей! 🎁
👉 Попробовать INFRAX
Реклама. ООО «АУДИТ-ТЕЛЕКОМ», ОГРН 1167746696776, erid: 2Vtzqv8Ag74
🚀 Kubernetes: зачем вообще нужны операторы?
Обычный Deployment или StatefulSet хорошо справляется с запуском подов. Но вот что делать, если у тебя есть сложная система - например, база данных с репликацией, кластер Kafka или Redis с шардингом? Просто манифестов будет мало.
Тут приходят Kubernetes Operators.
Оператор - это контроллер + CRD (Custom Resource Definition), который понимает, как управлять конкретным приложением:
- следит за состоянием ресурса,
- запускает нужное количество реплик,
- настраивает связи,
- делает бэкапы, обновления, миграции.
👉 По сути, оператор превращает знания SRE/админа в код, который работает прямо внутри кластера.
Примеры:
- Prometheus Operator - автоматом деплоит Prometheus, Alertmanager, ServiceMonitor.
- Postgres Operator - умеет поднимать кластера PostgreSQL с репликацией и бэкапами.
- Cert-Manager - автоматически выдает TLS-сертификаты.
🔑 В итоге операторы позволяют управлять сложными системами так же просто, как подами. Главное - не городить «свой велосипед», а искать готовые CRD, которые уже сделали другие.
Подпишись 👉@devopslib
🇷🇺 100% российская разработка
INFRAX — платформа all-in-one для управления ИТ-инфраструктурой:
✅ Мониторинг инфраструктуры (ITOM)
✅ Удаленный доступ для сотрудников и привилегированных пользователей
✅ Обработка заявок пользователей (ServiceDesk)
✅ База знаний с разграничением доступа к категориям (публичные и закрытые)
✅ Автоматизация (скрипты и планировщик)
✅ Контроль привилегированных пользователей. Видеозапись сессий RDP/SSH/VNC. (PAM)
✅ Управление доступами. Доступ ко всем корпоративным сервисам через одну учетку (IAM)
БЕСПЛАТНО до 100 пользователей! 🎁
👉 Попробовать INFRAX
Реклама. ООО «АУДИТ-ТЕЛЕКОМ», ОГРН 1167746696776, erid: 2Vtzqv8Ag74
⚡️ Чтение чужого Terraform - кода: боль и радость DevOps
Terraform сам по себе прост, но когда открываешь чужие модули - хочется закрыть ноутбук и уйти в отпуск.
Что обычно встречается:
- 100500 переменных в
variables.tf, половина из которых нигде не используется.
- "Универсальный" модуль: и под AWS, и под GCP, и под Azure - но работает только в одном.
- Output-хаос: чтобы понять, откуда берётся IP, нужно пройти 5 вложенных модулей.
- Нет документации — комментарии? README? Не, не слышали.
👉 Как выжить:
1. Начни с terraform graph | dot -Tpng > graph.png — визуализация сильно помогает понять связи.
2. Используй terraform console — можно проверить выражения прямо на лету.
3. Включи TF_LOG=DEBUG при планировании — увидишь, что реально под капотом.
4. И не стесняйся переписать модуль под себя — часто это быстрее, чем поддерживать чужую магию.
💡 Совет: заведите внутренний гайд по стилю Terraform (структура папок, нейминг, обязательный README). Это спасает нервы всей команды.
Подпишись 👉@devopslib
🔥 Открытый урок «GitLab CI + Ansible: автоматизация инфраструктуры без боли».
🗓 27 августа в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «CI/CD на основе GitLab».
🎯 На вебинаре разберем:
✔️ Как настроить GitLab CI для работы с Ansible
✔️ Организация пайплайна для автоматического запуска Ansible-плейбуков
✔️ Как тестировать и проверять изменения в Ansible до деплоя
✔️ Использование GitLab CI как среды для обучения и отладки Ansible
👥 Кому будет интересно:
- DevOps-инженерам, которые осваивают или уже используют GitLab CI и Ansible, и хотят связать их в единый, автоматизированный процесс
- Начинающим специалистам, изучающим инфраструктурный код и автоматизацию
- Техническим архитекторам, заинтересованным в построении масштабируемых и управляемых CI/CD процессов с Ansible
🎯 Что вы получите:
- Практическое понимание интеграции Ansible с GitLab CI
- Готовые идеи и примеры для запуска и тестирования Ansible-плейбуков
- Уверенность в использовании CI/CD пайплайнов для инфраструктурных задач и конфигурационного менеджмента
🔗 Ссылка на регистрацию: https://vk.cc/cOK1Sl
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🚦Проблемы с readinessProbe в Kubernetes
Часто бывает так: деплой прошёл, pod поднялся, но сервис не отвечает. Смотрим
kubectl get pods - статус Running. Но трафик всё равно не идёт. Почему?
👉 Ответ - неправильно настроенный readinessProbe.
Pod может быть «живым» (liveness ок), но ещё не готов принимать трафик. Например, приложение стартует 30 секунд, а проба выставлена на 5 - kube-proxy считает pod готовым слишком рано.
🔧 Что делать:
- Настраивайте initialDelaySeconds под реальное время старта.
- Проверяйте, что endpoint для probe быстрый и стабильный (не делайте запросы в БД).
- Используйте timeoutSeconds и failureThreshold, чтобы учесть сетевые лаги.
- Логи pod’а и kubectl describe pod — лучшие друзья для диагностики.
📊 Хорошая практика — сначала запускать приложение без probe, замерять время старта, а потом добавлять проверки с запасом.
Подпишись 👉@devopslib