💡 Многие девопсы недооценивают силу readiness и liveness проб в Kubernetes.

Проблема: без них kubelet считает под «живым», даже если приложение давно висит и не отвечает. В итоге у тебя в кластере «зелёные» поды, а пользователи шлют мат в поддержку.

👉 Разница:

LivenessProbe — проверяет, живо ли приложение. Если не отвечает - pod рестартует.
ReadinessProbe — проверяет, готов ли сервис обрабатывать трафик. Если нет - трафик не идёт, но pod не перезапускается.

⚙️ Частые ошибки:

- Делают одинаковый endpoint для обоих проб. В итоге под либо вечно рестартует, либо никогда не попадает в сервис.
- Ставят слишком жёсткие таймауты - приложение ещё грузит кэш, а kubelet уже думает «оно мёртвое».
- Забывают про startupProbe - и получают вечный рестарт на тяжёлых приложениях (например, Java с долгим стартом).

✅ Хорошая практика:

- liveness → простой healthcheck (например, GET /ping).
- readiness → что-то посложнее (например, проверка подключения к БД).
- startupProbe → обязательно для всего, что стартует дольше пары секунд.

Kubernetes умеет заботиться о твоих подах, но только если ты правильно объяснишь ему, что значит «жив» и «готов».

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

🚀 Как DevOps-инженеры мы часто увязаем в задачах автоматизации и забываем про «гигиену» инфраструктуры. А ведь простые проверки могут спасать от неприятных ночных алертов:

🔎 Периодически проверяй лимиты и квоты в облаке. Упёрся в лимит IP-адресов или дисков - и вот у тебя прод простаивает.

🧹 Смотри на orphan-ресурсы — старые volume, неиспользуемые load balancer’ы, забытые секреты в Vault. Всё это стоит денег и иногда может мешать.

🕓 Планируй регулярный audit logs review. Лишние сервисные аккаунты или подозрительная активность легко пропустить, если смотреть только на дашборды.

🛡 Не хардкодь секреты. Даже тестовые ключи лучше сразу класть в менеджер секретов, чтобы не ловить «утечку века» из git.

Внедрив маленькие привычки, можно сократить 80% неожиданных проблем и освободить время на то, что реально интересно.

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

🚨 Скрытые расходы старого CI/CD

Очень часто вижу, что команды годами используют один и тот же CI/CD, который когда-то «поставили и забыли». На первый взгляд всё работает: пайплайны крутятся, артефакты собираются. Но внутри копятся скрытые издержки:

🐌 Медленные билды - ожидание деплоя в 10–15 минут превращается в десятки потерянных часов в месяц.
💸 Железо и лицензии - старые агенты гоняются на жирных VM, которые никто не оптимизировал.
🤯 Сложность поддержки — только один человек знает, как там всё устроено. Уйдёт - полкоманды будет гадать, что за магия в YAML.
🔒 Безопасность - забытые токены, старые версии раннеров, отсутствие актуальных патчей.

👉 В итоге мы «платим налог» не деньгами напрямую, а временем и рисками.

Что можно сделать:

1. Поставить метрики времени сборок и деплоя - пусть будет видно реальные цифры.
2. Разобрать пайплайны: есть ли шаги, которые можно параллелить или кэшировать.
3. Проверить обновления агента/раннера. Иногда апгрейд даёт +50% к скорости.
4. Автоматизировать инфраструктуру CI/CD через код (Terraform, Ansible, Helm) - чтобы не зависеть от «человека-ключа».

CI/CD - это не просто труба для кодека, а живой сервис. И его тоже надо мониторить и оптимизировать.

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

💡 Сегодня немного про боль Kubernetes-кластеров

Когда у тебя всё крутится в k8s, кажется - удобно: автоскейлинг, изоляция, сервисы живут своей жизнью. Но как только в кластере начинают появляться десятки namespace и сотни подов, без нормальной политики ресурсов всё превращается в хаос.

👉 У каждого пода должны быть requests и limits. Если этого нет - кластер живёт как коммуналка без счётчиков: кто успел, тот и съел. Один жадный контейнер может легко задушить соседей.

👉 Мониторинг на уровне ResourceQuota и LimitRange реально спасает от «сюрпризов» в проде.

👉 А ещё - включите PodPriority и Preemption. Это даёт возможность критичным сервисам выжить, даже если какой-то non-prod под начал жрать всю память.

В итоге Kubernetes сам по себе не магия. Это инструмент. А инструмент требует гигиены и правил.

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

Облако 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.cloud Мощное облако. Честная цена. Люди на связи.

Реклама. ООО "АВАНГАРД", ОГРН 1107746046550, erid: 2VtzqxcZdhf

💥 Kubernetes хаос и как его приручить

Все красиво, пока не падает прод. А потом ты открываешь kubectl get pods и видишь 37 подов в статусе CrashLoopBackOff.
Kubernetes вроде как должен “самоисцеляться”, но иногда он просто сидит и смотрит, как всё горит 🔥

Вот три типичных источника хаоса и как их быстро приручить:

1. Liveness / Readiness пробы
Когда они настроены неправильно - поды убиваются зря.
👉 Проверь, что readinessProbe не стреляется слишком часто, и добавь initialDelaySeconds.
Удивительно, как часто это спасает от самоуничтожения.

2. OOMKilled
Если ты видишь это в kubectl describe pod - у тебя проблема с лимитами.
👉 Поставь requests чуть ниже среднего потребления, limits - чуть выше пика.
И не забудь включить VerticalPodAutoscaler - пусть сам подскажет реальные цифры.

3. NetworkPolicies и DNS
Часто блокируются сервисы внутри кластера, особенно CoreDNS.
👉 Минимальный тест: kubectl exec -it pod -- nslookup kubernetes.default.
Если не работает - смотри NetworkPolicy и iptables в CNI.

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

💥 Kubernetes хаос и решения. Часть 2 - «Боль автообновлений»

Если у тебя в кластере внезапно всё «упало» ночью, а утром тебя встретил alert с фразой “Pods not ready” - скорее всего, виноваты автообновления.

Сценарий классический:

- Включен auto-upgrade для node pool в GKE/EKS/AKS.
- Cloud-провайдер решил, что пора обновить kubelet и runtime.
- Worker-ноды перезагрузились, pods пошли в Terminating, Pending, а кластер стал частично неработоспособным.

Почему так происходит:

- Не настроены PodDisruptionBudgets (PDB).
- Нет стратегии drain с учётом приоритета workloads.
- Stateful приложения (Postgres, Kafka, Redis) теряют лидерство и консистентность.
- Контроллеры не успевают пересоздавать pod'ы из-за лимитов ресурсов или ошибок readinessProbe.

Как лечить:

1. Отключи автообновления для node pool - обновляй вручную.
2. Введи maintenance window, чтобы обновления шли только в заданные часы.
3. Определи PDB для всех важных pods - не более 1-2 одновременно недоступных.
4. Используй drain-сервис например, kured с контролем через annotations.
5. Тестируй обновления на staging-кластере - симулируй rolling drain.

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

🚨 Когда “сам себя перезапустил” — это не баг, а фича

Недавно один под обетом «никогда больше не трогать продакшн ночью» всё-таки зашёл “на минутку”.
Проверил pods, увидел CrashLoopBackOff, сделал kubectl delete pod, и - чудо - всё ожило!
Только через 10 минут понял, что просто три раза подряд перезапустил контейнер с тем же багом.

Moral of the story:
Не каждый автоперезапуск - спасение. Иногда Kubernetes просто смотрит на тебя и думает:

“Я делаю, что могу, но ты уверен, что хочешь, чтобы это продолжалось?”

🧠 Совет:
Если контейнер падает постоянно - не трогай pod. Смотри kubectl describe pod и kubectl logs -p.
Возможно, виноват init-контейнер, readiness-проба или ошибка в startup-скрипте.
И да - логи с -p спасают, когда под уже ушёл на перезапуск.

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