🚦Проблемы с 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

⚡️ Чтение чужого 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

🚀 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